www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - 'synchronized' broken?

reply "Kris" <fu bar.com> writes:
void main()
{
        Object [char[]] map;

        synchronized void test(char[] key)
        {
                Object x = map[key];
        }

        test ("foo");
}
Oct 28 2005
next sibling parent reply Stefan Zobel <Stefan_member pathlink.com> writes:
In article <dju0b3$2el5$1 digitaldaemon.com>, Kris says...

void main()
{
        Object [char[]] map;

        synchronized void test(char[] key)
        {
                Object x = map[key];
        }

        test ("foo");
}






No, it should be



 void test(char[] key)
 {
   synchronized {
     Object x = map[key];
   }
 }


see http://www.digitalmars.com/d/statement.html#synchronize

synchronized had never been doing anything the way you use it. Remember, it's
D not Java.

Kind regards,
Stefan
Oct 28 2005
next sibling parent Stefan Zobel <Stefan_member pathlink.com> writes:
In article <djucun$2r2b$1 digitaldaemon.com>, Stefan Zobel says...

No, it should be



 void test(char[] key)
 {
   synchronized {
     Object x = map[key];
   }
 }


see http://www.digitalmars.com/d/statement.html#synchronize

synchronized had never been doing anything the way you use it. Remember, it's
D not Java.


Oops, forget that - my mistake, sorry! Somehow I completely
missed that synchronized is also a valid storage class
(http://www.digitalmars.com/d/declaration.html). I was damn' sure

Coming from Java I actually prefer it this way :)

Kind regards,
Stefan
Oct 28 2005
prev sibling parent reply "Kris" <fu bar.com> writes:
 synchronized had never been doing anything the way you use it.


Au contraire. For example, the following syntactic-sugar is perfectly legal, 
as one would expect. It has been supported for all the time I've used D:






yet this, at module scope, produces a clear (and recent?) error message:





"function test.foo synchronized function foo must be a member of a class"

However the following is acceptable at module scope, as it is within class 
methods (previously, this particular syntax would sometimes hang the 
executable):






In the first case, the synch is upon the class instance, whereas in the 
third case (above) the synch is effectively on an implicit module-level 
object. That begs the question: why the error message in case two? Shouldn't 
it just synch on the same implicit module-level object as case three? I 
think it should.

In other words, 'synchronized' within the declaration itself is simply 
syntactic sugar; it effectively causes a synchronized block to be placed 
around the function statements ~ just like the explicit code in case three. 
It seems odd that one cannot use the former wherever one can use the latter.

The original example below does /not/ produce an error message for the 
sugary declaration of the nested function. Instead, it errors on the 
invocation instead. As such there's a diagnostic difference from example 
two, above. That is, said sugary declaration is accepted without error in 
the case of a nested function; just as it is when declaring a class method; 
whereas it is not accepted on a module-level declaration. Therefore:

1) there's a diagnostic bug. Specifically with respect to nested functions 
outside of a class.

2) there's the question as to why the sugary syntax isn't supported outside 
of a class.



 Remember, it's D not Java.


Such pointless & bigoted pontificating has no value or bearing upon this 
topic ~ thus, Stefan, it's really not very helpful. Let's not go there, 
please.




"Stefan Zobel" <Stefan_member pathlink.com> wrote in message 
news:djucun$2r2b$1 digitaldaemon.com...

 In article <dju0b3$2el5$1 digitaldaemon.com>, Kris says...

void main()
{
        Object [char[]] map;

        synchronized void test(char[] key)
        {
                Object x = map[key];
        }

        test ("foo");
}






 No, it should be



 void test(char[] key)
 {
   synchronized {
     Object x = map[key];
   }
 }


 see http://www.digitalmars.com/d/statement.html#synchronize

 synchronized had never been doing anything the way you use it. Remember, 
 it's
 D not Java.

 Kind regards,
 Stefan
Oct 28 2005
parent reply Stefan Zobel <Stefan_member pathlink.com> writes:
In article <djui7o$2vdb$1 digitaldaemon.com>, Kris says...

 Remember, it's D not Java.


Such pointless & bigoted pontificating has no value or bearing upon this 
topic ~ thus, Stefan, it's really not very helpful. Let's not go there, 
please.



Sorry for spreading this guff about synchronized, Kris.

I really was under the impression that the compiler ignores
it when applied to a method declaration. Someone said so on 
the NG, but I should have checked that before making such
unjustified claims, of course!

I didn't want to engage in Java bashing but rather caution
Java programmers against an imaginary (as I now know) pitfall.
In fact, I've made a living from Java programming for 6 years
and I actually like the language.

Kind regards,
Stefan
Oct 28 2005
parent "Kris" <fu bar.com> writes:
Didn't see your second post before replying. No worries!


"Stefan Zobel" <Stefan_member pathlink.com> wrote in message 
news:djum64$q1$1 digitaldaemon.com...

 In article <djui7o$2vdb$1 digitaldaemon.com>, Kris says...

 Remember, it's D not Java.


Such pointless & bigoted pontificating has no value or bearing upon this
topic ~ thus, Stefan, it's really not very helpful. Let's not go there,
please.



 Sorry for spreading this guff about synchronized, Kris.

 I really was under the impression that the compiler ignores
 it when applied to a method declaration. Someone said so on
 the NG, but I should have checked that before making such
 unjustified claims, of course!

 I didn't want to engage in Java bashing but rather caution
 Java programmers against an imaginary (as I now know) pitfall.
 In fact, I've made a living from Java programming for 6 years
 and I actually like the language.

 Kind regards,
 Stefan
Oct 28 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Kris" <fu bar.com> wrote in message news:dju0b3$2el5$1 digitaldaemon.com...

 void main()
 {
         Object [char[]] map;

         synchronized void test(char[] key)
         {
                 Object x = map[key];
         }

         test ("foo");
 }





synchronized isn't supported for nested functions, because it conflicts with
the SynchronizedStatement. What you can do, though, is wrap the statements
inside the function in a synchronized statement:

void test(char[] key)
{
    synchronized { Object x = map[key]; }
}
Oct 28 2005
parent reply "Kris" <fu bar.com> writes:
Thanks, Walter.

Just out of interest, can you expand upon why the declarative sugar is 
disallowed at module-scope, while synch{} blocks are supported?

For example:





Why is foo() OK, but bar() not? Doesn't the sugar just add a synch-block 
around the interior function statements?



"Walter Bright" <newshound digitalmars.com> wrote in message 
news:djufq0$2ta8$3 digitaldaemon.com...

 "Kris" <fu bar.com> wrote in message 
 news:dju0b3$2el5$1 digitaldaemon.com...

 void main()
 {
         Object [char[]] map;

         synchronized void test(char[] key)
         {
                 Object x = map[key];
         }

         test ("foo");
 }





 synchronized isn't supported for nested functions, because it conflicts 
 with
 the SynchronizedStatement. What you can do, though, is wrap the statements
 inside the function in a synchronized statement:

 void test(char[] key)
 {
    synchronized { Object x = map[key]; }
 }
Oct 28 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Kris" <fu bar.com> wrote in message news:djuim4$2vl9$1 digitaldaemon.com...

 Thanks, Walter.

 Just out of interest, can you expand upon why the declarative sugar is
 disallowed at module-scope, while synch{} blocks are supported?

 For example:





 Why is foo() OK, but bar() not? Doesn't the sugar just add a synch-block
 around the interior function statements?


At the moment it isn't supported because the class member function version
uses the 'this' pointer as its monitor. There is no monitor for the module
scope one, though it could be supported by using the global monitor.
Oct 28 2005
next sibling parent "Kris" <fu bar.com> writes:
OK ~ thank you for the clarification.

"Walter Bright" <newshound digitalmars.com> wrote in message 
news:djutjq$6tn$1 digitaldaemon.com...

 "Kris" <fu bar.com> wrote in message 
 news:djuim4$2vl9$1 digitaldaemon.com...

 Thanks, Walter.

 Just out of interest, can you expand upon why the declarative sugar is
 disallowed at module-scope, while synch{} blocks are supported?

 For example:





 Why is foo() OK, but bar() not? Doesn't the sugar just add a synch-block
 around the interior function statements?


 At the moment it isn't supported because the class member function version
 uses the 'this' pointer as its monitor. There is no monitor for the module
 scope one, though it could be supported by using the global monitor.
Oct 28 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <djutjq$6tn$1 digitaldaemon.com>, Walter Bright says...

"Kris" <fu bar.com> wrote in message news:djuim4$2vl9$1 digitaldaemon.com...

 Thanks, Walter.

 Just out of interest, can you expand upon why the declarative sugar is
 disallowed at module-scope, while synch{} blocks are supported?

 For example:





 Why is foo() OK, but bar() not? Doesn't the sugar just add a synch-block
 around the interior function statements?


At the moment it isn't supported because the class member function version
uses the 'this' pointer as its monitor. There is no monitor for the module
scope one, though it could be supported by using the global monitor.


Out of curiosity, how are synchronized statements within function blocks
handled?  Do they all synchronize on the global monitor?  I noticed a linked
list of critical sections in critical.c, but it isn't clear when this is used
vs. when the global monitor is used.


Sean
Oct 28 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <djv644$eai$1 digitaldaemon.com>, Sean Kelly says...

Out of curiosity, how are synchronized statements within function blocks
handled?  Do they all synchronize on the global monitor?  I noticed a linked
list of critical sections in critical.c, but it isn't clear when this is used
vs. when the global monitor is used.


Actually, to take it a step further:

class C {
synchronized void f1() {} // synch on class instance
synchronized static void f2() {} // does this work?  synch on classinfo instance
}

void f3() {
synchronized{} // synchronize on global monitor?
}

I think those are all the forms of synchronized.  Am I correct about how it all
works, or does the block in f3 gets its own (non-global) critical section?


Sean
Oct 29 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
You're correct in how it works.
Oct 30 2005