Re: "Fix" the semantics of synchronized

[<P.H.Welch@xxxxxxxxx>]

Oyvind wrote:

> Why are these things associated with "semantics of synchronized"?
> I thought the only problem with synchronized was that they had
> not defined how threads inside synchronized running a wait() are
> queued - fifo or lifo?

No.  There is also the problem of how threads are managed that cannot
proceed becuase they are trying to get a monitor lock in the first place
- i.e. by trying to invoke a "synchronized" method or trying to enter
a "synchronized" block.  Are they managed on a queue, a `weak' queue,
a stack or what?!!  Java does not specify and any management is allowed.

The above is a separate issue as to how threads are managed when they
"wait" on a monitor (having first acquired the lock via "synchronized").
Here, also, Java does not specify how they wait.

The two issues raise the same question, but they are two issues.

In JCSP and CTJ, the second issue is not a problem.  We arrange things
so that there is never more than *one* process (thread) doing a "wait"
on any particular monitor.  So, how such processes are managed is not
an issue - there is only one of them!

For 1-1 channels, the first issue is not a problem either.  Again, only
one process (either the single reader or the single writer) may be blocked
as it synchronises on the channel.  This blocking is by its partner (i.e.
the single writer or the single reader).  So, how processes blocked on
a "synchronized" are managed does not matter.

Only for many-1, 1-many and many-many channels is this first issue
relevant.  There, many processes (e.g. writers) may be blocked by an
associate (i.e. another writer to the same many-1 or many-many channel),
who has acquired the (writer-)lock and is "wait"ing for a reader.

So, if Bill can get the "semantics of synchronized" tightened sufficiently
so that a guarantee is given that any attempt to synchronize will always
succeed (which a stacking management does not guarantee), I'm happy.
I'm not bothered about the "wait" semantics :-)

The above request needs just a little clarification.  The sought guarantee
is one against failure by starvation, not failure by deadlock.  If your
system is not deadlock-free, than an attempt to "synchronize" may fail.
Suppose the code inside the "synchronized" method or block involves no
other "syncs" or "waits" - just pure computation.  Then, I want the
guarantee that I will get through into "synchronized" code sometime,
no matter what other threads may be doing.  And for real-time systems,
of course, I want some way of putting an upper bound on that sometime!

Cheers,

Peter.