[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 166 - Let's try it again
Hello Ron: > Agreed, the meaning of the phrase "atomic assignment" > is unclear in the context of the assign activity. Section 14.3 is clear. It is the case that either all the variable copies within an assign activity succeed, or they are retain their original value before the assign. Moreover atomic has a very well understood meaning in computer science. From looking at Yaron's examples, I don't think he is clear on the notion of atomicity. > The assign activity is atomic; that is, the assign > activity MUST be executed as if, for the duration of >its execution, it was the only activity in the process > allowed the following: None of what you said guarantees atomicity. > The main point here is to avoid mandating a single lock > on all process state data, forcing single threading > whenever assigns are being This is a low level implementation detail. It is easy to abstractly describe atomicity without resorting to talking about low level operating system artifacts like threads and locks. And it is possible (and sometimes desirable) to implement atomicity without using locks. >My question is: do we need to add some extra language >to avoid possible deadlocking in >such a scheme, or do we leave that as an >exercise for the implementor? :-) Ron, you should leave the implementation of atomicity as an exercise for the BPEL engine implementor. Cheers, Andrew
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]