synchronized { }

[Sean Kelly]

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.

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