mit-scheme-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MIT-Scheme-devel] non-recursive mutexes


From: Arthur A. Gleckler
Subject: [MIT-Scheme-devel] non-recursive mutexes
Date: Mon, 8 Jun 2015 13:40:35 -0700

On Monday, June 8, 2015, Taylor R Campbell <address@hidden> wrote:
 
Hi, Arthur!  I asked the list last year whether anyone relied on it:

https://lists.gnu.org/archive/html/mit-scheme-devel/2014-11/msg00005.html

Nobody replied that they relied on it, and since the thread system is
undocumented I expected its use outside the tree to be limited.

Oops.  Sorry, I somehow I missed that.
 
The reason I decided to do this is that it is practically always a
mistake to rely on recursion: for each mutex, you should know whether
or not you hold it at each point when you need access to the resource
it protects, and you should know what other locks are held in order to
determine a consistent lock order.

In each case where I'm using them, there really is only one lock, so lock order is not an issue.  Other locks that are not part of the system and are held by callers are not relevant because third-party code is never called in the contexts of the sections those locks control.

I know, in each case, that I need access to the resource being protected.  That's why I'm acquiring the lock.  The only question is whether is has already been acquired.
 
Utility routines whose callers might or might not hold the lock are
suspect and tend to suggest insufficiently considered design:  What is
the invariant the lock provides?  If the caller doesn't need to hold
the lock, why does the lock need to be there at all?

Here's an example: I have a web server whose internal data structures are rarely mutated.  I use a lock to prevent conflicts.  I also use that lock to serialize the server's write access to its logs.  My logging procedures are sometimes called by the server while it holds the lock, and sometimes when it doesn't already hold the lock.  Rather than have two variants of each logging procedure, one that expects the lock to be held already and one that acquires it, I used recursive locks.  Now I can't do that, at least with what's built into MIT Scheme.
 
There are legitimate cases where recursive locks make sense, but most
uses are best served by a nonrecursive lock abstraction.  You can
always build a recursive lock out of a nonrecursive lock and a
condition variable.

That's more complicated and prone to error.

I'll look over my code again, but all the cases where I am using recursive mutexes are of that flavor.

Anyway, thanks for the explanation, and sorry for missing your earlier message.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]