== Quote from Graham St Jack (graham.stjack@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@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?


Sean

Steven Schveighoffer wrote:
> "torhu" wrote
>> Steven Schveighoffer wrote:
>>> In any case, Tango avoids needing this statement by making mutexes fully accessible objects.  If you need a mutex without having it attached to an object, it's easy:
>>>
>>> Mutex m = new Mutex;
>>>
>>> synchronized(m)
>>> {
>>> }
>>
>>
>> Isn't that the same as doing this?
>>
>> ---
>> Object m = new Object;
>>
>> synchronized(m)
>> {
>> }
> 
> It's close, but in Tango, you have methods for the mutex, plus you can use them with conditions.
> 
> Plus, it's not as hackish :)

Sure, but my point was just that your example doesn't do anything that my example doesn't.

Sean Kelly wrote:
> == Quote from Graham St Jack (graham.stjack@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@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.

== Quote from torhu (no@spam.invalid)'s article
> Sean Kelly wrote:
> > == Quote from Graham St Jack (graham.stjack@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@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.


Sean

"Sean Kelly" <sean@invisibleduck.org> wrote in message news:g4bhn1$ufo$1@digitalmars.com...

> Um, it /is/ equivalent to synchronized(this).  What made you think differently?

Uh?  In the OP:

-----
Right now, if you use a synchronized statement with no argument, it will sync on a mutex unique to that statement.
-----

Doesn't seem like synchronized(this) to me.

== Quote from Jarrett Billingsley (kb3ctd2@yahoo.com)'s article
> "Sean Kelly" <sean@invisibleduck.org> wrote in message news:g4bhn1$ufo$1@digitalmars.com...
> > Um, it /is/ equivalent to synchronized(this).  What made you think
> > differently?
> Uh?  In the OP:
> -----
> Right now, if you use a synchronized statement with no argument, it will sync on a mutex unique to that statement.
> -----
> Doesn't seem like synchronized(this) to me.

I'd hate to disagree with Walter since he created D, but I don't know that
there's even a means of doing this in the runtime right now.  Storage is
reserved for a single global monitor which is shared by all free functions
and probably all functions in structs as well since there's no room to
store a per-instance monitor for them (I never bothered to verify the
behavior with structs, so I'm making an educated guess).  Also, each
object instance gets its own monitor which is shared by all non-static
class member functions.  Finally, static class member functions use
the monitor on the TypeInfo object for that class.

This aside, synchronizing in the manner implied by Walter's remark would be largely useless anyway, since it's quite common for multiple functions to share access to some resource and all such functions must synchronize on the same mutex.  Better to be safe and synchronize everything on a single global mutex that try for performance and end up using multiple unrelated mutexes for the same operation.  If this is truly the way that Phobos 2.0 works, well... I suppose that's one more reason I'd be glad I'm using Tango.


Sean

== Quote from Sean Kelly (sean@invisibleduck.org)'s article
> == Quote from torhu (no@spam.invalid)'s article
> > Sean Kelly wrote:
> > > == Quote from Graham St Jack (graham.stjack@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@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

Sean Kelly wrote:
> == Quote from Sean Kelly (sean@invisibleduck.org)'s article
>> == Quote from torhu (no@spam.invalid)'s article
>>> Sean Kelly wrote:
>>>> == Quote from Graham St Jack (graham.stjack@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@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).

Why is the current behavior broken?

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

Bruno Medeiros wrote:
> Sean Kelly wrote:
>> == Quote from Sean Kelly (sean@invisibleduck.org)'s article
>>> == Quote from torhu (no@spam.invalid)'s article
>>>> Sean Kelly wrote:
>>>>> == Quote from Graham St Jack (graham.stjack@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@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

Sean Kelly wrote:
> Bruno Medeiros wrote:
>> Sean Kelly wrote:
>>> == Quote from Sean Kelly (sean@invisibleduck.org)'s article
>>>> == Quote from torhu (no@spam.invalid)'s article
>>>>> Sean Kelly wrote:
>>>>>> == Quote from Graham St Jack (graham.stjack@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@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