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

[<andrew.francis@mail.mcgill.ca>]

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