On Monday, June 8, 2015, Taylor R Campbell <campb...@mumble.net <javascript:_e(%7B%7D,'cvml','campb...@mumble.net');>> 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.
_______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
