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

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

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