Date: Mon, 8 Jun 2015 13:40:35 -0700 From: "Arthur A. Gleckler" <sch...@speechcode.com>
On Monday, June 8, 2015, Taylor R Campbell <campb...@mumble.net> wrote: > 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. It sounds like you would be better served by having two locks: the web server's data structure lock, and the logging lock. The logging lock can be internal to the logging routines, and need not be exposed elsewhere in the web server at all. I'll look over my code again, but all the cases where I am using recursive mutexes are of that flavor. In my experience, the added error detection of rejecting recursive locks -- and the resulting pressure to make it clear what's locked where and why, and to identify invariants and distinguish unrelated ones -- outweighs the convenience of avoiding the extra FROBNICATE/LOCKED routine every once in a while. The few cases actually requiring nontrivial recursion tend to have much more nuanced requirements than the normal mutex API can provide, e.g. reader/writer semantics with cheap readers to support suspending all operations without adding overhead (particularly interprocessor synchronization) to every operation[1]. [1] http://netbsd.gw.com/cgi-bin/man-cgi?fstrans++NetBSD-current _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
