Proposals: Synchronization

[Bruno Medeiros]

Sean Kelly wrote:
> Kent Boogaart wrote:
>> 2. Don't permit arbitrary locking of objects.
>>
>> It is well accepted amongst the Java and .NET communities that 
>> allowing locking of arbitrary objects is a bad thing. For example, 
>> this is considered bad practice:
>>
>> public void myMethod()
>> {
>>     ...
>>     lock (this)
>>     {
>>         ...
>>     }
>> }
>>
>> It is bad because any other code could lock the object refered to by 
>> this. That can result in deadlocks, race conditions and all sorts of 
>> weird behavior. The accepted practice is:
>>
>> private object _lock = new object();
>>
>> public void myMethod()
>> {
>>      ...
>>      lock (_lock)
>>      {
>>          ...
>>      }
>> }
>>
>> That way only the owning class can lock on the object.
>>
>> So my suggestion is to disallow locking on arbitrary objects and 
>> change the lock keyword to only allow locking on a Phobos-provided 
>> Lock class like this:
>>
>> private Lock _lock = new Lock(); //the Lock class or struct is 
>> implemented in Phobos
>>
>> public void myMethod()
>> {
>>     lock (_lock)  //OK
>>     {
>>     }
>>
>>      lock (this) {} //compile error
>>
>>      lock (new object()) {} //compile error
>> }
>>
>> I would also suggest NOT allowing this syntax:
>>
>> public lock(_lock) void myMethod()
>> {
>> }
>>
>> Because it is ugly and synchronization is an implementation detail 
>> that should be kept out of the method signature.
>>
>> Pros:
>>    - the synch block can be removed from every object stored on the gc 
>> heap (that's a saving of at least 4 bytes per gc object - that's huge 
>> for applications that allocate a lot of small objects)
>>    - programmers are forced to lock in a safer manner. The problems of 
>> Java / .NET locking on arbitrary objects are avoided.
>>    - D will be able to provide better diagnostics of locks as a 
>> program runs and during debug sessions. Locks could be named, for example
>>
>> Cons:
>>    - none that I can think of
> 
> This would make this currently legal syntax illegal:
> 
> void fn() {
>     synchronized {
>         // stuff
>     }
> }
> 
> ie. where the synchronization object is implicit.  I suppose its value 
> is debatable, but I think it's sufficiently useful that I wouldn't want 
> it to be illegal.
> 
> 
> Sean

Hum, I'm attracted to the idea that D's Objects would not have to have 
the monitor data. (altough I can't clearly say that the performance gain 
will be significative)

I understand the "synchronized { ... }" statement might be useful, so 
perhaps we can have the best of both worlds? What if the implicit 
synchronized statement would call, similarly to operator overloading, a 
predefined lock function (or monitor member). Then we could have a mixin 
that would make a class lockable, by adding a monitor member, and 
perhaps a lock method. Such mixin should be defined by the standard lib, 
so that the user would not be required to write one. Then we would have 
code like this:

   class Foo {
     mixin Lockable; // std.thread.Lockable ?

     void fn() {
       synchronized {
         ... // stuff
       }
     }
   }

which isn't that much more verbose, and now regular Objects would not 
have the monitor member.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D