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

[Regan Heath]

On Wed, 30 May 2012 00:10:19 +0100, Jonathan M Davis <jmdavisProg at gmx.com>  
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?

Not in all cases.  If you have a synchronized class, say a thread-safe  
container, which has a synchronized lookup and synchronized insert  
function, code like..

if (!o.lookup(...))
   o.insert(...)

obtains and releases the mutex twice each, and in between another thread  
could call o.insert() and insert the missing object - resulting in 2  
copies being inserted (or a duplicate insert exception being throw, or...).

Now, the above is bad design, but the only other choice is to expose  
lock() and unlock() methods (or the mutex - back to square 1one) to allow  
locking around multiple class, but now the caller has to be careful to  
call unlock in all code paths.  scope helps us in D, but this is actually  
the whole point of synchronized blocks - 1. ensuring the unlock always  
happens and 2. making the scope of the locking visible in the code.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/