On 30-05-2012 01:10, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 01:02:53 Alex Rønne Petersen wrote:
But mutexes allow proper encapsulation by hiding the mutex resource. As
I've proven in the very OP of this thread, both druntime and phobos
suffer from the anti-pattern that is locking on a public resource when
you shouldn't. The language encourages doing it with this synchronized
business.
From your comments, it sounds to me like the problem is entirely with
synchronized blocks, not sychronized classes. Synchronized classes don't have
the issue of having externals lock on them without the explicit use of
synchronized blocks. They're the equivalent of locking a mutex in every public
function and releasing it afterwards. The problem is that that mutex is
effectively public such that when a synchronized block is used on it, it locks
on the same mutex. If no synchronized blocks are used, as far as I can tell,
it's a non-issue.
As such, wouldn't simply making the use of a sychronized block on a
synchronized object illegal fix the problem?
- Jonathan M Davis
Possibly. I haven't thought that through, but I think that that could
work. In fact, it would probably be a good way to ensure safety
statically, since a synchronized class tells its user "I take care of
synchronization".
We still have the issue of every object having a monitor, but that is
probably a separate issue...
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
