[RFC] "lock" statement and "mutex" type.

[Sean Kelly]

BCS wrote:
> Dejan Lekic wrote:
>> My suggesion in form of lock(someMutex) {} else {} satisfies both type of
>> concurrent programming fans. If you do not want lock to try, than just
>> forget else block. :) Without else block lock() would behave like
>> pthread_mutex_lock(), with else block it would behave like
>> pthread_mutex_trylock() . Yes, i agree conditional variables should 
>> also be
>> there, however i did not think so much about how to do it...
>>
> 
> One other thought: How should deadlock be handled?
> 
> options:
>     1> it's not, that's the programmer's problem.
>     2> some unspecified, the compiler/runtime just does it.
>     3> multiple locks can be requested at the same time e.i.
> 
>         lock(mutex1, mutex2) // block untill mutex 1&2 can both be held

Either 1 or 3.

>        but no more can be acquired until the first ones are released.

No.  It's not unusual to need more locks later if you're using a lock 
heirarchy.  Only locks on the same level must be acquired 
simultaneously.  That said, this whole lock business is a huge pain, and 
I'm hoping we can do better with D.  Herb Sutter gave a talk on his 
Concur library for C++ the other day, and the ideas seem pretty 
reasonable (though he didn't really answer my question on how to handle 
the possibility of multiple parallel exceptions in C++ -- perhaps not an 
issue in D).  In any case, I may try doing something similar in D.  I 
think delegates might make the whole process quite streamlined.


Sean