On Tuesday, 13 October 2015 at 18:27:43 UTC, Jonathan M Davis
wrote:
they should be creating multiple mutexes. Having a single mutex
for a class is usually overly broad - regardless of whether all
of the functions in a class are synchronized or only select
ones are. And when you _do_ use a single mutex for an entire
class, I've found that it's often the case that the mutex
Monitor classes is a high level convenience feature that one has
to put work into if it is to be good. It is however much less
error prone than mutexes and semaphores.
The point is that you create a robust encapsulated facade and
only weaken the facade after static analysis has proven that
locks are superfluous. Doing this manually is error prone.
One can also add high level concurrency mechanisms like
guarantees for obtaining a set of resources before obtaining the
lock, e.g. the caller supplies a predicate like "user Eric and
user Lisa is available" and is suspended until the predicate is
satisfiable.
But it needs more high level features than D has today.
