[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 166 - Does atomicity in assign imply variable locking?
Hello: > Description: Section 14.3 of the spec requires that >assigns be atomic. But it isn't clear if the definition >of the term atomic encompases placing a read and write >lock on the manipulated variables during the execution >of the assign. For example (stolen from Danny): Atomicity requires that either all of the assign, or none of the assign succeeded. Why does the specification have to state whether a read/write lock is used to guarantee atomicity? This sounds like an implemenation detail to me. I think Section 14.3 is on the right track and nothing is wrong with it. > Making programmers figure out how to deal with >atomic non-locking behavior (and no, that isn't necessarily > a contradiction), seems perverse. I beg to differ. The atomicity makes reasoning about the code simpler. Also a guarantee of atomicity results in correct behaviour. >The easy solution would appear to be to declare that >assigns >always execute in an implicit serialzable scope This does not address the fundamental issue: atomic assignment. Even if one's scope is serialised, a throwcan leave one's assigment in an unstable state. Imagine an implementation where a variable assign that under the hood, involves a few operations on a DOM and for whatever reason (i.e., the thread doing the operations is killed) does not get to complete. Cheers, Andrew
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]