OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


my personal interpretation of andrew's comment was that locking and 
atomicity are orthogonal, in which andrew and i violently agree on ;-)



Yaron Y. Goland wrote:

> 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
>>
>>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. 
>
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]