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
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
>
>
