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

[Micah Brodsky]

Hi, Taylor.
+1 for Arthur on this. I don't know whether my RPC library relies anywhere
on recursive locking, but I'm not currently maintaining it and I'd really
rather not have the most difficult parts of it (i.e. thread management) rot
out from under me while I'm busy with other projects. 

In general, deciding whether to make breaking changes based on whether or
not there is a reply to one or two postings on an obscure mailing list is a
lousy strategy for software ecosystem stewardship. Speaking as an alum of
MS's application compatibility group, if you don't want your users hating
your guts, the default assumption needs to be that breaking changes are
unacceptable until proven otherwise. "Encouraging good coding practice" is
hardly justification to wing it.

--Micah

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf
Of Taylor R Campbell
Sent: Monday, June 08, 2015 3:02 PM
To: Arthur A. Gleckler
Cc: MIT Scheme Developers
Subject: Re: [MIT-Scheme-devel] non-recursive mutexes

   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=d7241d6fe8b151f6
d15db9cac8fba44b074ca215>.
   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.

_______________________________________________
MIT-Scheme-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel