On 2014-03-16 04:08:18 +0000, Andrei Alexandrescu
<[email protected]> 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
[email protected]
http://michelf.ca
