synchronized (this[.classinfo]) in druntime and phobos

Alex Rønne Petersen alex at lycus.org
Tue May 29 16:22:38 PDT 2012


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
alex at lycus.org
http://lycus.org


More information about the Digitalmars-d mailing list