Again: Native threads

[Robert S. Thau]

  2) the mutex implementation of some Posix threads differs from Tim's
     mutexes: If one mutex is locked then it can't be locked again by
     the same thread, otherwise there we get an deadlock. With Tim's
     mutexes one thread *may* get a mutex a second time.

FWIW, this behavior is required for mutual exclusion in the monitors
associated with Java objects, by the language spec (which also has a
moderately detailed description of how wait() and signal() are meant
to behave in a thread which has grabbed a mutex multiple times).  If
the VM is running on a native threads package that doesn't provide a
set of counting mutex primitives, that means that it will presumably
have to count the multiple grabs itself, to track which release of a
lock actually does release it, as opposed to being nested.  (This is
not hard, of course).

Of course, this requirement isn't binding on mutexes used internally
by the VM itself for its own purposes, so long as those non-counting
mutexes are not visible to user code, or at least not visible as the
locks associated with monitors of normal Java objects (which someone
might try to use as the target of a synchronized() statement --- use
which would require the full Java monitor semantics).

rst