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?

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?

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.

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/

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.

"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

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

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?

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

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.