Synchronized classes have no public members

[Ola Fosheim Grøstad via Digitalmars-d]

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.