www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - synchronized { }

reply Walter Bright <newshound1 digitalmars.com> writes:
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?
Jun 25 2008
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 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 tried to once but the design quickly outgrew the method. I wouldn't miss it. What inspires you to abandon or replace it?
Jun 25 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 Walter Bright Wrote:
 
 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 tried to once but the design quickly outgrew the method. I wouldn't miss it. What inspires you to abandon or replace it?

The idea that there isn't a legitimate use for it.
Jun 25 2008
parent BCS <ao pathlink.com> writes:
Reply to Walter,

 Jason House wrote:
 
 Walter Bright Wrote:
 
 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?
 

miss it. What inspires you to abandon or replace it?


How about replace it by allowing any global (of any type) to be used. A global mutex would need to be created in such a cases.
Jun 26 2008
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
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. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jun 26 2008
parent reply Graham St Jack <graham.stjack internode.on.net> writes:
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.
Jun 29 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
== 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.


Um, it /is/ equivalent to synchronized(this). What made you think differently? Sean
Jun 30 2008
next sibling parent reply torhu <no spam.invalid> writes:
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.


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.
Jun 30 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
== 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.


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

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
Jun 30 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
== 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.


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

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.

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
Jul 27 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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?

an incorrect assumption obviously. If you get rid of it, I won't miss it.



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.

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
Jul 30 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
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?

synchronize(this) {}, an incorrect assumption obviously. If you get rid of it, I won't miss it.


differently?

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.

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=digitalmar .D.bugs&artnum=5268 http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmar .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
Jul 30 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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?

synchronize(this) {}, an incorrect assumption obviously. If you get rid of it, I won't miss it.


differently?

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.

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=digitalmar .D.bugs&artnum=5268 http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmar .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
Aug 04 2008
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Jun 30 2008
parent Sean Kelly <sean invisibleduck.org> writes:
== 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?

----- 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
Jun 30 2008
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote
 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?

Yeah, that seems not too useful, it only makes sense when writing functions that use global data. In that case, it makes more sense to synchronize on the data instead of the code that accesses the data. Otherwise, if you eventually have to access the data through other code, then you have to switch to synchronizing on the data anyways. And if you forget to switch, then you now have a subtle bug :) Better to force coders to think about why they are synchronizing and lock the appropriate object. -Steve
Jun 26 2008
prev sibling next sibling parent "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Thu, 26 Jun 2008 04:18:41 +0300, Walter Bright  
<newshound1 digitalmars.com> wrote:

 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 think I used it once for: void write_synced(string s) { synchronized writef("%s", s); } or maybe it was some other external resource not linked to a class. -- Best regards, Vladimir mailto:thecybershadow gmail.com
Jun 26 2008
prev sibling next sibling parent reply cemiller <chris dprogramming.com> writes:
I use it on occasion. It can be useful for singleton:

    if(!foo)
    {
       synchronized
       {
          if(!foo)
             foo = new Foo();
       }
    }
    return foo;

especially useful because you don't need an object instance.


On Wed, 25 Jun 2008 18:18:41 -0700, Walter Bright  
<newshound1 digitalmars.com> wrote:

 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?

Jun 26 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to cemiller,

 I use it on occasion. It can be useful for singleton:
 
 if(!foo)
 {
 synchronized
 {
 if(!foo)
 foo = new Foo();
 }
 }
 return foo;
 especially useful because you don't need an object instance.
 

Hmmm. Slight variation on my last suggestion, Allow synchronized to take any global symbol as the mutex if(!foo) { synchronized(Foo) // global mutex on Foo { if(!foo) foo = new Foo(); } } Or if you need more resolution: class Foo { alias void single; } ... synchronized(Foo.single) // global mutex on Foo.single ...
Jun 26 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"cemiller" wrote
 On Thu, 26 Jun 2008 16:42:32 -0700, BCS wrote:

 Reply to cemiller,

 I use it on occasion. It can be useful for singleton:
  if(!foo)
 {
 synchronized
 {
 if(!foo)
 foo = new Foo();
 }
 }
 return foo;
 especially useful because you don't need an object instance.

Hmmm. Slight variation on my last suggestion, Allow synchronized to take any global symbol as the mutex if(!foo) { synchronized(Foo) // global mutex on Foo { if(!foo) foo = new Foo(); } } Or if you need more resolution: class Foo { alias void single; } ... synchronized(Foo.single) // global mutex on Foo.single ...

I could synchronized(typeid(Foo)) but I don't think D guarantees that each type has its own instance and monitor. This could potentially be a substitute; create a type and lock on it, no runtime allocation, not many language changes needed.

I think this is guaranteed as long as you are not loading D from multiple DLLs. 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) { } -Steve
Jun 27 2008
parent reply torhu <no spam.invalid> writes:
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) { } ---
Jun 27 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"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 :) It would be nice if the language supported conditions based on the Monitor object by default. -Steve
Jun 27 2008
parent torhu <no spam.invalid> writes:
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.
Jun 30 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from torhu (no spam.invalid)'s article
 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)
 {
 }

--- Object m = new Object; synchronized(m) { } ---

No. Mutexes in Tango can be set as the monitor for any object, and are in fact their own monitors. So synchronized(m) actually locks the Mutex, not a separate monitor object associated with the Mutex object. You can just as easily do this: class C { this(Mutex x) { m = x; setMonitor(this, m); } Mutex m; void fn() { // the following are all equivalent synchronized {} synchronized(this) {} synchronized(m) {} } } Ore read-write mutexes: ReadWriteMutex m; synchronized(m.reader) {} synchronized(m.writer) {} Sean
Jun 30 2008
prev sibling parent cemiller <chris dprogramming.com> writes:
On Thu, 26 Jun 2008 16:42:32 -0700, BCS <ao pathlink.com> wrote:

 Reply to cemiller,

 I use it on occasion. It can be useful for singleton:
  if(!foo)
 {
 synchronized
 {
 if(!foo)
 foo = new Foo();
 }
 }
 return foo;
 especially useful because you don't need an object instance.

Hmmm. Slight variation on my last suggestion, Allow synchronized to take any global symbol as the mutex if(!foo) { synchronized(Foo) // global mutex on Foo { if(!foo) foo = new Foo(); } } Or if you need more resolution: class Foo { alias void single; } ... synchronized(Foo.single) // global mutex on Foo.single ...

I could synchronized(typeid(Foo)) but I don't think D guarantees that each type has its own instance and monitor. This could potentially be a substitute; create a type and lock on it, no runtime allocation, not many language changes needed.
Jun 26 2008
prev sibling next sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g3uqph$2s3n$1 digitalmars.com...
 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?

Never understood that one, so: no. But I do think there's a place for synchronized { }: memory barrier. IIRC a mutex always implies a memory barrier anyway. synchronized without argument could only create a memory barrier. This could then be used to achieve what the Interlocked* functions in Win32 do. It's such a basic operation that I think it warrants a language construct. static int b;//some global int a;//local // native cross-platform InterlockedIncrement synchronized { a = b++; } I should note however that I'm currently having a hard-time implementing some multi-threaded algorithms.. I probably don't know enough about MT to be messing with it :S L.
Jun 26 2008
prev sibling next sibling parent downs <default_357-line yahoo.de> writes:
gentoo-pc ~ $ cat test50.d; echo "==="; gdc test50.d -o test50 && ./test5
0
import std.stdio;

template _SyncObject(string KEY) {
  Object obj;
  static this() { obj = new Object; }
}

template SyncObject(string KEY) {
  alias _SyncObject!(KEY).obj SyncObject;
}

void main() {
  writefln(SyncObject!("main_1") is SyncObject!("main_1"));
  writefln(SyncObject!("main_1") !is SyncObject!("main_2"));
  synchronized (SyncObject!("main_1")) {
    writefln("Test");
  }
}
===
true
true
Test
Jun 27 2008
prev sibling next sibling parent reply janderson <askme me.com> writes:
Walter Bright wrote:
 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?

Slightly off topic. Just a thought. If we had the ability to do block operators, or turn functions with delegates into blocks, or any other incarnation we could have this as a library function. -Joel
Jun 27 2008
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from janderson (askme me.com)'s article
 Walter Bright wrote:
 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?

Just a thought. If we had the ability to do block operators, or turn functions with delegates into blocks, or any other incarnation we could have this as a library function.

It is already effectively a library function in Tango. Tango contains mutexes which may operate as object monitors and there is no real code dependency for this between the runtime and library code. Sean
Jun 30 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 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?

It's certainly convenient in some instances, but obviously not necessary. Still, I find the current behavior to be easily understandable. Sean
Jun 29 2008