Re: [wsbpel] Issue - 166 - Let's try it again

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

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