← Prev in month ← Prev in thread

Serializable Scopes Issues?

From
Ron Ten-Hove <>
Date
2003-10-17T16:29:47+00:00
ID
Thread
Serializable Scopes Issues?
I've been contemplating serializable scopes for a few minutes, and
I have a few concerns that may be issues, or perhaps just inputs into
the existing issue asking for the spec to be clearer on how such scopes
work. Regardless, I'd like to run these past the TC:

    The spec suggests that serialized scopes should be regarded as
being similar to the serialized isolation level in database
transactions. Following this suggestion, I can imagine two basic styles
of implementation:

  
Pessimistic Lock Style. Scopes acquire suitable read and write
locks to assure the isolation characteristics required. 

  

  
Optimistic Lock Style. Scopes, upon closing, check to ensure that
variables being updated haven't been already updated by some other
(contending) scope (possibly unserialized?)

The first case leads to the interesting, and in my opinion undesirable,
case of serializing execution of concurrent scopes. (It has been
asserted elsewhere on this list that serializable scopes can be
implemented by a "sufficiently eccentric thread scheduler," which I
believe falls into this category.) Thus a flow, executing several
concurrent scopes with serialized variable access may in fact execute
in a completely serial fashion. We should either a) clarify that this
is expected/allowed, or b) direct conforming implementations to avoid
this behaviour.

    The second case, optimistic lock style, introduces a new fault
type, which occurs when a completing serialized scope attempts to
update a shared variable that has been updated by some other
scope/process after the completing scope started.  Should we have a
standard fault for this scenario? Should it be possible to recover from
such an error, through some sort of application retry?

    Finally, would it be useful to allow a serialized scope to have
greater control over which shared variables are included in the
serialized access group? In other words, would it be better to have a
way of explicitly including (or, conversely, excluding) outer variables
into (or from) those given serialized access in the scope, rather than
including everything? 

    Which brings up another question: should we ban, in <from>
general expressions, the ability to indirectly refer to variable names?
(I vaguely remember that Arkin (?) raised this issue, possibly in
another context, but I can't find it in the issues list.)   

-Ron
← Prev in month ← Prev in thread