Synchronized classes have no public members

[Marco Leise via Digitalmars-d]

Am Tue, 13 Oct 2015 09:36:22 +0000
schrieb ponce <contact at gam3sfrommars.fr>:

> On Tuesday, 13 October 2015 at 09:07:54 UTC, Chris wrote:
> > On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut 
> > wrote:
> >>
> >> […] The entire synchronized methods give the user the feeling
> >> that he simply slaps synchronized on his class / method and
> >> then its thread safe and he doesn't have to care about threads
> >> anymore. In the real world this is far from true however. So
> >> synchronized methods and classes just give a false sense of
> >> thread safety and should rather be removed.
> >
> > Actually, I once fell foul of this wrong impression of thread 
> > safety via 'synchronized'. I found a different solution and 
> > dropped synchronized.
> 
> I also dropped synchronized and use @nogc mutexes instead. I also 
> think synchronized methods should be removed. It's also difficult 
> to explain: what is a "monitor"? when you write a synchronized { 
> } block, which monitor is taken?

Yep, I prefer to think it sets of variables that need mutex
protection. And these are not generally the set of member
fields in a class. When other mutexes need the same variables
they must be a strict superset or subset of the other with the
mutex with smaller scope always being locked first.

That's all folks. 100% safety. :)
(The catch is you need to get a fix on the variables.)

-- 
Marco