Issue - 166 - Does atomicity in assign imply variable locking?

[ws-bpel issues list editor<peter.furniss@choreology.com>]

This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if the TC accepts it as identifying a bug in the spec or decides it should be accepted specially. Otherwise it will be closed without further consideration (but will be marked as "Revisitable")

The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue - 166 - Does atomicity in assign imply variable locking?

Status: received
Date added: 29 Sep 2004
Categories: Data handling
Date submitted: 27 September 2004
Submitter: Yaron Y. Goland
Description: Section 14.3 of the spec requires that assigns be atomic. 
But it isn't clear if the definition of the term atomic encompases 
placing a read and write lock on the manipulated variables during the 
execution of the assign. For example (stolen from Danny):
int counter
counter = 0
flow
    sequence
       counter = counter + 1;
       if (counter == 2) {
          throw "counter is 2"
       }
    sequence
       counter = counter + 1;
       if (counter == 2) {
          throw "counter is 2"
       }
If assign doesn't imply placing a read/write lock on variables 
referenced in the assign then it is possible for the previous code to 
exit without ever throwing a fault. After all, both assigns could 
execute simultaneously, both read in the same value (0), both add 1 and 
both write out the same counter value, 1 and thus both end without 
throwing a fault.
Submitter's proposal: Writing parallel code under the best of 
circumstances is very difficult. Making programmers figure out how to 
deal with atomic non-locking behavior (and no, that isn't necessarily a 
contradiction), seems perverse. The easy solution would appear to be to 
declare that assigns always execute in an implicit serialzable scope but 
this 'easy' solution causes some conceptual problems in the case that 
the scope the assign is a member of is itself already serializable. This 
edge case matters because of:
scope variableAccessSerializable="yes"
    flow
       assign
          ...
       assign
          ...

Links: Danny van der Rijn, 18 Sep 2004     
Assaf Arkin, 18 Sep 2004     
Danny van der Rijn, 20 Sep 2004
Changes: 29 Sep 2004 - new issue

---

To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 166 - [anything]" or is a reply to such a message. If you want to formally propose a resolution to an open issue, please start the subject line "Issue - 166 - Proposed resolution", without any Re: or similar.

To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).