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

[Alex Rønne Petersen]

On 30-05-2012 19:12, Andrei Alexandrescu wrote:
> On 5/30/12 9:23 AM, Alex Rønne Petersen wrote:
>> On 30-05-2012 18:14, Andrei Alexandrescu wrote:
>>> This is news to me. How do you publicly access the mutex of a
>>> synchronized class object?
>>
>> Generally in two ways:
>>
>> 1) synchronized (obj)
>
> This is not accessing the mutex for arbitrary operations.

No, it is indeed not. You didn't explicitly say you wanted to do 
"arbitrary operations", so I assumed that by accessing the mutex you 
meant doing the only two things that are sensible for a mutex: Locking 
and unlocking it. What else would you want to do? This discussion has 
always been about locking and unlocking publicly exposed mutexes. I 
don't think arguing about "arbitrary operations" is going to get the 
discussion anywhere exactly because of what you proceed to say ...

>
>> 2) obj.__monitor
>
> All symbols starting with two underscores are reserved by the
> implementation.

... since that effectively means there is no way, from an 
implementation-independent standpoint, to alter the memory of a mutex 
(or whatever) (see my answer below), thus making the only sensible 
operations on a mutex locking and unlocking.

But I may be misunderstanding you. If so, please clarify and/or correct me.

(Just so we're clear, I included (2) only for completeness. I know it's 
a dirty hack and I agree that it should never be in the language 'spec' 
or TDPL.)

>
>> (1) accesses it in order to actually do locking, but if obj is an
>> instantiation of a class that uses the this reference internally for
>> locking, you end up with potential deadlocks.
>
> Deadlocks are endemic to mutex-based programming and are not avoided
> inherently or preferentially by the alternative you discussed (exposing
> unrestricted mutex).
>
>> Therefore, you can say
>> that obj's mutex is exposed.
>
> Nothing could stop one, but that claim is incorrect.

It is exposed as far as using it for anything sensible goes. No, 
synchronized (obj) does not let you delete the monitor of obj or alter 
it or something along these lines, but I don't think that's worth 
bringing into this argument. This has always been about locking and 
unlocking a publicly exposed mutex, and about preventing common deadlock 
sources.

>
>
> Andrei

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org