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

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

You're correct in how it works.