+1. i re-assert that technically, the spec is pretty
clear to me. <assign> is atomic. nothing is said about
consistency, isolation, or durability. if this needs to be made
explicit, it should be done.
if the TC wishes to make <assign> isolated as well, which i
strongly object to, i assert that we must then examine anything else
that can change process state. a partial list is <invoke>,
<receive>, <throw>. again, there is already a construct
for isolation, and it is serializable scopes.
danny
Ron Ten-Hove wrote:
Andrew,
There is some confusion in this conversation, arising from
terminology. The term "atomic" has been turned, by some, into a synonym
for ACID. This is incorrect. The term atomic simply means that changes
to the shared variables are made at once, indivisibly, or not at all.
Consistency, isolation, and durability are separate concerns, and are
not required by the current specification. I believe Danny and Yaron
have illustrated this point well.
Atomic assignment, by itself, leaves us with some open questions
about concurrent behaviour. This is well illustrated by the "concurrent
counter" example that has been floated on this thread. The fact that
various members of this TC have different intepretations of the
behaviour of the example suggests that the current wording of section
14.3 is unclear, and that we need to address this.
As for implementors: I worry about specifications that are
ambiguous, and leave it up to implementors to interpret things as best
they can. This is a guaranteed way to kill portability and
interoperability. As a TC authoring a public standard, we must be very
clear about what we mean. Clearly we need to work on section 14.3
before the expected behaviour of implementations is clearly,
unambigiously expressed. We can then allow implementors (including you
and me) to do their thing.
Cheers,
-Ron
andrew.francis@mail.mcgill.ca
wrote:
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
|