synchronized { }

Bruno Medeiros brunodomedeiros+spam at com.gmail
Mon Aug 4 10:52:25 PDT 2008


Sean Kelly wrote:
> Bruno Medeiros wrote:
>> Sean Kelly wrote:
>>> == Quote from Sean Kelly (sean at invisibleduck.org)'s article
>>>> == Quote from torhu (no at spam.invalid)'s article
>>>>> Sean Kelly wrote:
>>>>>> == Quote from Graham St Jack (graham.stjack at internode.on.net)'s 
>>>>>> article
>>>>>>> On Thu, 26 Jun 2008 08:15:24 -0400, Michel Fortin wrote:
>>>>>>>> On 2008-06-25 21:18:41 -0400, Walter Bright 
>>>>>>>> <newshound1 at digitalmars.com>
>>>>>>>> said:
>>>>>>>>
>>>>>>>>> Right now, if you use a synchronized statement with no 
>>>>>>>>> argument, it
>>>>>>>>> will sync on a mutex unique to that statement.
>>>>>>>>>
>>>>>>>>> Does anyone write threading code that depends on this behavior?
>>>>>>>> I've used it before, thinking it was equivalent to 
>>>>>>>> synchronize(this) {},
>>>>>>>> an incorrect assumption obviously. If you get rid of it, I won't 
>>>>>>>> miss
>>>>>>>> it.
>>>>>>> Same.
>>>>>> Um, it /is/ equivalent to synchronized(this).  What made you think 
>>>>>> differently?
>>>>>>
>>>>> Don't the docs say that they're not equivalent?
>>>>> http://www.digitalmars.com/d/2.0/statement.html#SynchronizedStatement
>>>>> I thought they were the same too, before Walter checked in 
>>>>> something to
>>>>> phobos that made me think otherwise.  Can't remember what exactly.
>>>> They're identical, unless something changed recently in D 2.0.  
>>>> Walter confirmed
>>>> this explicitly for me a while back, though I don't have a link handy.
>>>
>>> I was finally inspired to track down the reference for this statement:
>>>
>>> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.bugs&artnum=5268 
>>>
>>> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.bugs&artnum=5276 
>>>
>>>
>>> The second post from Walter is a reply to my post in the first link.  
>>> Given
>>> this, I can only assume that Walter either misunderstood me or that 
>>> the behavior
>>> was changed silently at some point--I'm pretty sure the latter since 
>>> I tested
>>> this way back when.  In any case, the current behavior is as Walter 
>>> described,
>>> and I consider it utterly broken.  Not only is it inconsistent with 
>>> Java, which
>>> is what I believe this design was based on, but it's completely 
>>> useless in the
>>> general case.  It has to change, but I really wish that the behavior 
>>> could be
>>> fixed in D 1.0 as well.  Not likely I know, but oh well.
>>>
>>>
>>> Sean
>>
>> What do you mean inconsistent with Java? I checked it out now, and 
>> apparently Java does not have a synchronized statement with no 
>> arguments 
>> (http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.19). 
> 
> 
> See:
> 
> http://java.sun.com/docs/books/jls/third_edition/html/classes.html#260369
> 
> I would consider a synchronized statement with no arguments within a 
> class member function to synchronize on the same monitor as a 
> synchronized function in Java.  I believe Walter has even said in the 
> past that 'synchronized' with no arguments is the D equivalent of the 
> synchronized function label in Java.
> 
>> Why is the current behavior broken?
> 
> I'm stating that based on Walter's description above where such blocks 
> will "sync on a mutex unique to that statement."  Obviously, the whole 
> point of synchronization is coordinating the efforts of multiple 
> concurrent threads.  However, in my experience it's unheard of to have a 
> single function be the means with which shared data is accessed.  And 
> not even a single function in this case, but a single statement.  For 
> example, let's say that we have a linked list that needs synchronization 
> because we're reading from it and writing to it concurrently.  How often 
> would both the read and write operations be done in the exact same 
> synchronized statement in code?  Right, never.
> 

Yes, it's not useful in that case. But it might be useful in a situation 
where the synchronized statement is the only statement/block with access 
to a certain shared global data.

For example, what about cemiller's use of the synchronized statement for 
singleton initialization (see his OP)?

> One could argue that a synchronized statement with no supplied 
> expression should simply always synchronize on the global monitor, since 
> that monitor can't be supplied explicitly.  However, I would argue that 
> the correct behavior is to default to the immediate context surrounding 
> the function.  So a class member function would sync on the class 
> instance, a static class function would sync on the static classinfo, 
> and a global function would sync on the global monitor.  Simple, 
> straightforward, and it corresponds to the most common use cases for 
> synchronization.
> 
> 
> Sean

Whatever the case, you do agree it's not a major problem what the 
no-args synchronized statement does, since it is only syntactic sugar 
for the with-args version? (Like I said, Java doesn't even have a 
no-args synchronized statement)

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D



More information about the Digitalmars-d mailing list