Re: [wsbpel] Issue - 166 - Does atomicity in assign imply variablelocking?

["Yaron Y. Goland" <ygoland@bea.com>]

So you are asserting that by defining assign as atomic we prevent the 
case I described?

If so then you and Danny are in violent disagreement.

		Yaron

andrew.francis@mail.mcgill.ca wrote:
> 
> 
> Hello Yaron:
> 
>  >You assert that variable locking is irrelevant to the BPEL
>  >>programming model.
> I am "asserting" that one does not need to resort using
> variable locking to describe the atomicity of assignment.
> 
>  >I don't understand how this assertion can be defended
>  >given the example
> <http://lists.oasis-open.org/archives/wsbpel/200409/msg00361.html>.>
>  >If there is no variable locking then it is possible for the
>  >>assign statements in the example in the linked message,>lets call 
> them A and B, to execute as follows:
> 
>  > Assign A - Read in counter value
>  > Assign B - Read in counter value
>  > Assign A - Increment counter value and write
>  > Assign B - Increment counter value and write
> 
> Sorry I don't agree with this statement. You are not
> describing an atomic operation: atomic operations are
> indivisible. Since assign is  atomic, then I feel the
> following is a more accurate, but simplified description
> of what happens:
> 
> Assign A - Read in counter value. Increment counter value
> and write.Assign B - Read in counter value. Increment counter value
> and write.
>  > If we don't specify that assign requires isolation semantics
> 
> I think atomic assign operation is much more of an issue
> .... and a challenge for the BPEL engine implementer.
> BPEL engine implementers  probably won't have the luxury
> of dealing with data structures that have support from
> atomic operations in a lower layer (i.e., the hardware).
> 
> Cheers,
> Andrew
> 
>