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

["Eckenfels. Bernd" <B.Eckenfels@seeburger.de>]

Hello Andrew,

actually atomic has both meanings, in a get/set operation atomic often means "isolated". In a multi-output scenario it often means "wont observ partial result". There is also the rollback case in which it means "all or no changes are applied", which is a specialized case of "no partial results".

I think we can agree that "all or none changed" and  "not partially" are the requirements which are at least required. The requirement for isolation is not something you expect in other features, however looking at the minimum requirmeents (especially rollback) I dont see a way an implementation will not also gurantee isolation, so we can as well require it.


BTW: neat technical detail: in java assignes to double+long variables are not expected to be atomic in the sence that a reader thread may  see a value the var never had.

Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de


-----Original Message-----
From: andrew.francis@mail.mcgill.ca
[mailto:andrew.francis@mail.mcgill.ca]
Sent: Wednesday, October 06, 2004 7:30 PM
To: Ronald.Ten-Hove@Sun.COM
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 166 - Let's try it again


Hello Ron:

>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.

I think the concurrent behaviour argument is specious.
My simple approach to the problem is to ask myself the
question:

"Can a race condition occur on an atomic operation"?

"Atomic" by definition, denotes indivision. The answer
is "no": what is there to race to besides the single
instruction?  Would we be having the same argument
if it were say an assembly level test-and-set instruction
or an instruction that executed in one CPU clock cycle?


Cheers,
Andrew




To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.