Am Tue, 13 Oct 2015 09:36:22 +0000 schrieb ponce <cont...@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