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");
}

# foo.d(10): undefined identifier test
# foo.d(10): function expected before (), not test of type int 
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");
}

# foo.d(10): undefined identifier test
# foo.d(10): function expected before (), not test of type int 

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 that the statement is the only way to do it (like lock in C#). 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: # class Foo # { # synchronized void foo(){} # } yet this, at module scope, produces a clear (and recent?) error message: # synchronized void foo() {} # # void main() {} "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): # void main() # { # synchronized {/* do something */} # } 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");
}

# foo.d(10): undefined identifier test
# foo.d(10): function expected before (), not test of type int

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");
 }

 # foo.d(10): undefined identifier test
 # foo.d(10): function expected before (), not test of type int

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:

# module x;
# void foo() {synchronized{//OK}}
# synchronized void bar() {//error}

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");
 }

 # foo.d(10): undefined identifier test
 # foo.d(10): function expected before (), not test of type int

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:

 # module x;
 # void foo() {synchronized{//OK}}
 # synchronized void bar() {//error}

 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:

 # module x;
 # void foo() {synchronized{//OK}}
 # synchronized void bar() {//error}

 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:

 # module x;
 # void foo() {synchronized{//OK}}
 # synchronized void bar() {//error}

 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