[Bordeaux-threads-devel] Deprecating recursive locks

[Vladimir Sedach]

Another argument against recursive locks that hasn't come up yet is
that they fail very badly when used with condition variables. I think
the fact that recursive locks aren't supported by most implementations
plus the fact that they behave differently wrt condition variables on
different implementations and operating systems are very good
arguments for leaving recursive locks out of a portable threading
library.

Vladimir

On Wed, May 2, 2012 at 3:10 PM, Antony <lisp.linux at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> Bordeaux-threads-devel mailing list
> Bordeaux-threads-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel