On 4/17/2012 8:21 AM, Stelian Ionescu wrote:
They're an ugly hack, as described their inventor David Butenhof (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive lock, but it's not a posix recursive lock), so I was thinking of making a 1.0 release in which to remove them altogether.
What do you think ?
I use CCL at the moment Not having recursive locks makes locking code more complicated. With recursive locks I only need to think about ensuring order when more than one lock is involved. Without recursive lock, every possible call path to every lock needs to be thought through.
I confirmed that CCL does support recursive locking http://clozure.com/pipermail/openmcl-devel/2012-May/013536.html
FWIW for .net http://msdn.microsoft.com/en-us/library/de0542zz%28v=vs.71%29.aspx "It is legal for the same thread to invoke Enter more than once without it blocking"
for java http://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html "a thread can acquire a lock that it already owns" (so I assume ABCL does recursive locks)
I read the message by Dave Butenhof http://groups.google.com/group/comp.programming.threads/msg/d835f2f6ef8aed99... that I think was pointed as the logic behind getting rid of recursive mutexes in bordeaux. I did a basic read. I am not an expert. I came to the conclusion, that he is confounding having a short duration hold on a lock with having a single lock request within a thread. That is, he is using the call stack depth to imply longer code, or in other words he is coming from the world of large functions. Even though those two things correlate often, that does not meean I can not have a couple of small functions each containing a with-... macro that does locking and then not have to bother with which exact combinations of mutual calls can happen among them.
While I agree it would be good if my code worked without recursive locks, I think I'd prefer having recursive locks. I do think of keeping locked duration short, but I don't scratch my head around call sequences within a thread requesting the same lock.
Unlike any other aspect of CL, threading in CL is very immature and removing this support is not going to help. I hope the decision to remove support will be reconsidered and some alternative like runtime/compile error will be implemented for implementations that don't support recursive locks..
-Antony