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