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
