TLBB: The Last Big Breakage

[Michel Fortin]

On 2014-03-16 04:08:18 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> Fixing that has not gained focus until recently, when e.g. 
> https://github.com/D-Programming-Language/dmd/pull/3067 has come about.

Synchronized classes should be trashed.

The whole concept is very prone to mistakes that could cause deadlocks 
and offers no simple path to fix those errors once they're found. The 
concept encourage people to keep locks longer than needed to access the 
data. For one thing is bad for performance. It also makes callbacks 
happen while the lock is held, which has a potential for deadlock if 
the callback locks something else (through synchronized or other means).

Sure, there are safe ways to implement a synchronized class: you have 
to use it solely as a data holder that does nothing else than store a 
couple of variables and provide accessors to that data. Then you build 
the business logic -- calculations, callbacks, observers -- in a 
separate class that holds your synchronized class but does the work 
outside of the lock.

The problem is that it's a very unnatural way to think of classes. Also 
you have a lot of boilerplate code to write (synchronized class + 
accessors) for every piece of synchronized data you want to hold. I bet 
most people will not bother and won't realize that deadlocks could 
happen.

Is there any example of supposedly well-written synchronized classes in 
the wild that I could review looking for that problem?

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca