Re: Proposal for issue 1003 - Relinquishing control of output channels

Updated wording, to:

1) make it clear that 'distinct' usage pattern only allows a channel instance to be used from a single concurrent thread within a choreography, and

2) make it clear that 'shared' usage pattern must avoid using the same operation on the same channel instance in concurrent threads (interference)

If this wording is acceptable, then possibly we could get this out of the way on the next conf call. If anyone is not going to be present on the call, but would like to register their agreement or disagreement with the updated wording, then please send your response to the list.


Regards
Gary


  Hi

  This proposal slightly changes the values associated with the ChannelType 'usage' attribute to enable it to support the three modes of linearity previously discussed by Kohei, which also implicitly defines whether channel types are relinquished when passed, and therefore addresses this issue (1003).

  1) Change syntax in 2.3.4

  from:
<channelType  name="ncname"
              usage="once"|"unlimited"?
              action="request-respond"|"request"|"respond"? >to: 
<channelType  name="ncname"
              usage="once"|"distinct"|"shared"?
              action="request-respond"|"request"|"respond"? >

  2) Change: 
  The OPTIONAL attribute usage is used to restrict the number of times a Channel of this Channel Type can be used. 

  to:

  The OPTIONAL attribute usage is used to constrain the way in which an instance of this Channel Type can be used. The values that can be used for this attribute are:

  (1) "once"

  This usage pattern indicates that a choreography can make use of a channel instance only once. This may be used in situations where single acknowledgement or callback interaction is required.

  (2) "distinct" (NOTE TO GROUP: not sure of the best term for this)
   
  This is the default usage pattern, which allows a channel instance to be used multiple times, but that only one concurrent thread within a single participant is permitted to act as the client role for the channel instance. Therefore, if a participant passes the channel instance to another participant, then this constraint dictates that the original participant can no longer use the channel instance, as they have relinguished control over the client side of the channel instance.

  (3) "shared" (NOTE TO GROUP: equivalent to the current "unlimited" value)

  This usage pattern is the least constrained, as it enables more than one participant (and concurrent thread within a participant) to share a reference to the client side of a channel instance. Therefore, if the original participant passes the channel instance to another participant, both the sending and receiving participants have access to the channel instance. The only restriction is that it MUST NOT be possible for two or more concurrent threads, within a participant, to be able to interact using the same operation, on the same channel instance, at the same time. This situation would prevent the server side of the channel instance being able to determine which thread had performed the interaction.
   



  NOTE: Reason for change is:

  1) To enable a choreography to indicate when a passed channel should be relinquished (i.e. solves issue 1003)

  2) To provide the basis for model checking based on linearity, without having to provide a detailed technical explanation within the CDL specification. This more indepth discussion, with explanation of linearity and the associated model checking approach, will be part of a separate "supplement". The text above has been approved by Kohei and Nobuko.


  Regards
  Gary