www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [RFC] "lock" statement and "mutex" type.

reply Dejan Lekic <dejan nu6.org> writes:
I think D should have mutex type and lock statement as part of D language,
in the similar fashion as in Modula-3.

D programmer would than be able to write:

mutex myMutex;

lock (myMutex)
{
  doSomething();
} else {
  continueSomething();
}

What do others think about this?
Reason for this above is that my personal opinion is that D should be the
language with full support for threads. I would even add "thread" keyword
somehow...

Kind regards

Dejan
Mar 14 2006
parent reply Sean Kelly <sean f4.ca> writes:
Dejan Lekic wrote:

 I think D should have mutex type and lock statement as part of D language,
 in the similar fashion as in Modula-3.
 
 D programmer would than be able to write:
 
 mutex myMutex;
 
 lock (myMutex)
 {
   doSomething();
 } else {
   continueSomething();
 }
 
 What do others think about this?


I'm not familar with that.  What's the behavior?  Is it a tryLock where 
the else block handles the failure?  Does the syntax account for lock 
acquisition with a timeout?  That said, I agree that D needs better 
concurrency support, and that broader mutex support is one aspect of 
this.  In particular, I'd at least like to have some way to not wait 
indefinitely for a lock to become available.


Sean
Mar 14 2006
parent reply Dejan Lekic <dejan nu6.org> writes:
Hi Sean,
yes, i did not think about acquisition with a timeout maybe following syntax
change is what we would like to have:
lock (<mutex variable>[, timeout]) 

You understood everything else. My was plain simple trylock. Following code
is an example of code without try:

lock (myMutex) // blocks calling thread
{
  doSomething();
}

as we slightly changed the main idea (from my previous post), we could have
something like:

lock (myMutex, 1000) // blocks calling thread for 1 second
{                    // if mutex "myMutex" is not unlocked during that time
  doSomething();     // it will exit the lock() block and execute continue()
}                    // function.
continue();


Regards

-----------
Dejan Lekic
  http://dejan.lekic.org
Mar 14 2006
parent reply BCS <BCS_member pathlink.com> writes:
The simple tryLock would allow for timeout:

while(!timeout())
{
   lock(mutex)
   {
     go();
     break;
   }
   else
     continue;
}

A bit clunky but...

I'm glad that native support for threads is being considered, I think that it 
would be a vary good thing. It would allow for some quite nice features like:

thread t1;

t1.run = &fn;	// launch thread

if(t1mustDie) t1.throw new KillThread;	// throw an exception in t1



Dejan Lekic wrote:

 Hi Sean,
 yes, i did not think about acquisition with a timeout maybe following syntax
 change is what we would like to have:
 lock (<mutex variable>[, timeout]) 
 
 You understood everything else. My was plain simple trylock. Following code
 is an example of code without try:
 
 lock (myMutex) // blocks calling thread
 {
   doSomething();
 }
 
 as we slightly changed the main idea (from my previous post), we could have
 something like:
 
 lock (myMutex, 1000) // blocks calling thread for 1 second
 {                    // if mutex "myMutex" is not unlocked during that time
   doSomething();     // it will exit the lock() block and execute continue()
 }                    // function.
 continue();
 
 
 Regards
 
 -----------
 Dejan Lekic
   http://dejan.lekic.org
Mar 14 2006
parent reply Dejan Lekic <dejan nu6.org> writes:
BCS, on contrary - it is not considered - that is why I began this
thread... :) So far all participants in this discussion agrees that D
(language) needs this what we discuss. Sure everything depends on Mr.
Bright.

-----------
Dejan Lekic
  http://dejan.lekic.org
Mar 14 2006
parent reply Graham St Jack <grahams acres.com.au> writes:
Dejan Lekic wrote:

 BCS, on contrary - it is not considered - that is why I began this
 thread... :) So far all participants in this discussion agrees that D
 (language) needs this what we discuss. Sure everything depends on Mr.
 Bright.
 
 -----------
 Dejan Lekic
   http://dejan.lekic.org
 



I agree that better threading support is needed in D. The synchronized 
keyword is a great start, but more is needed.

My opinion is that try_lock() on a mutex isn't a good idea - it is 
better to use conditions. You use mutexes to keep threads "apart" from 
each other (the synchronized keyword does this very well), making sure 
that no thread retains a lock for long.

You use conditions to enable a thread to "block" for potentially 
extended periods, without any thread retaining a lock on the mutex.

A couple of other related posts are:
http://www.digitalmars.com/d/archives/digitalmars/D/31340.html
http://www.digitalmars.com/d/archives/digitalmars/D/34392.html
Mar 14 2006
parent reply Dejan Lekic <dejan nu6.org> writes:
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...
Mar 14 2006
parent reply BCS <BCS_member pathlink.com> writes:
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

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

	4> other.
Mar 15 2006
parent Sean Kelly <sean f4.ca> writes:
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
Mar 15 2006