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?
 


 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.
 


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.


 Same.


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.


 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.
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.


 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
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.


 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
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?


 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 


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?


 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=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 



See:



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?


 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=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 



 
 
 See:
 

 
 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?


 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
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
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 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
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)
 {
 }


 Isn't that the same as doing this?
 ---
 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 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?


 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.


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