Re: [MIT-Scheme-devel] non-recursive mutexes

[Taylor R Campbell]

   Date: Sun, 7 Jun 2015 14:37:17 -0700
   From: "Arthur A. Gleckler" <address@hidden>

   I'm just upgrading to MIT Scheme 9.2, and my code is breaking in several
   places because of your change to Remove support for recursion in
   WITH-THREAD-MUTEX-LOCKED
   
<http://git.savannah.gnu.org/cgit/mit-scheme.git/commit/?id=d7241d6fe8b151f6d15db9cac8fba44b074ca215>.
   Can you tell me why you made that change?  I can't see a correctness or
   performance advantage, and the change list comment gives no justification.
   Not supporting recursion is a nuisance in cases where one has utility
   procedures that may or may not be run in a context where the lock is
   already held.

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.

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.

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?

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.