[Bordeaux-threads-devel] Deprecating recursive locks

[Antony]

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?hl=en&pli=1
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