I agree that writing parallel code is difficult. The proper way to aid
parallelism, IMO, would be to support it the way so many other
parallelized environements do: with semaphores and mutexes. However,
our spec does not have this functionality. The closest we come is
serializable scopes, which force programmers to think like DBAs.
Without going down the route of explicit mutexes, I would strongly
recommend against solving this problem with this proposal with its implicit
read- and write-locks.
For language in the spec that currently warns against parallel
pitfalls, see section 12.5.1:
"To determine the status for each link its transitionCondition
is evaluated. Note that the evaluation is carried out with the actual
values of the variables referenced in the transition condition
expression. If some of the
variables are modified in a concurrent behavior path, the result of the
transition condition evaluation may depend nondeterministically on
the timing of behavior among concurrent activities. "
and 13.3.2:
"Compensation handlers always use the current state of the process,
specifically the state of variables declared in their associated scope
and all
enclosing scopes. The variables include partnerLinks at the process
scope. Compensation handlers are able to both get and set the values
of
all such variables. Other parts of the process will see the changes
made
to shared variables by compensation handlers, and conversely,
compensation
handlers will see changes made to shared variables by other parts of
the
process, including situations where a compensation handler runs
concurrently
with other parts of the process. Compensation handlers will need to
use
serializable scopes when they touch state in enclosing scopes to avoid
interference if concurrency is expected."
My objections to the proposal are several:
- Why should locking only apply to <assign>? Because it is
apparently short lived? What if someone puts a custom XPath function
into an assign, and it takes a long time? What then? Should
<assign> also lock out the implicit assignment that occurs via
<invoke>, <receive>, and <pick>?
- I worry that engines are going to have to pay a not-insignificant
performance penalty in locking variables where that locking is not
needed.
- At what level is the lock to be taken? Can an assignment to $foo/bar
and $foo/baz occur simultaneously, or must they be serialized?
Lastly, as a process note, I would submit that adding implicit read-
and write-locks is a new feature, and should not be thought of as a bug.
Danny
Yaron wrote:
This issue has been added to the wsbpel issue list with a status
of "received".
The status will be changed to "open" if the TC accepts it as
identifying a bug in the spec or decides it should be accepted
specially. Otherwise it will be closed without further consideration
(but
will be marked as "Revisitable")
The issues list is posted as a Technical Committee document to the
OASIS
WSBPEL TC pages
on a regular basis. The current edition, as a TC document, is the most
recent version of the document entitled in the "Issues" folder of the WSBPEL
TC document list
- the next posting as a TC document will include this issue.
The list editor's working copy, which will normally include an issue
when it is announced, is available at this
constant URL.
Issue - 166 - Does atomicity in assign imply variable locking?
Status: received
Date added: 29 Sep 2004
Categories: Data handling
Date submitted: 27 September 2004
Submitter: Yaron Y. Goland
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):
int counter
counter = 0
flow
sequence
counter = counter + 1;
if (counter == 2) {
throw "counter is 2"
}
sequence
counter = counter + 1;
if (counter == 2) {
throw "counter is 2"
}
If assign doesn't imply placing a read/write lock on variables
referenced in the assign then it is possible for the previous code to
exit without ever throwing a fault. After all, both assigns could
execute simultaneously, both read in the same value (0), both add 1 and
both write out the same counter value, 1 and thus both end without
throwing a fault.
Submitter's proposal: Writing parallel code under the best of
circumstances is very difficult. Making programmers figure out how to
deal with atomic non-locking behavior (and no, that isn't necessarily a
contradiction), seems perverse. The easy solution would appear to be to
declare that assigns always execute in an implicit serialzable scope
but this 'easy' solution causes some conceptual problems in the case
that the scope the assign is a member of is itself already
serializable. This edge case matters because of:
scope variableAccessSerializable="yes"
flow
assign
...
assign
...
Links: Danny
van der Rijn, 18 Sep 2004
Assaf
Arkin, 18 Sep 2004
Danny
van der Rijn, 20 Sep 2004
Changes: 29 Sep 2004 - new issue
To comment on this issue (including whether it should be
accepted), please follow-up to this announcement on the
wsbpel@lists.oasis-open.org list (replying to this message should
automatically send your message to that list), or ensure
the subject line as you send it starts "Issue - 166 -
[anything]" or is a reply
to such a message. If you want to formally propose a resolution to an
open issue, please start the subject line "Issue - 166 - Proposed
resolution", without any Re: or similar.
To add a new issue, see the issues procedures document (but the
address for new issue submission is the sender of this announcement).
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.
|