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

[Taylor R Campbell]

   Date: Mon, 8 Jun 2015 21:29:52 -0700
   From: "Arthur A. Gleckler" <address@hidden>

   On Monday, June 8, 2015, Taylor R Campbell <address@hidden> wrote:

   > 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.

   The log file is specific to the particular web server instance, so the lock
   that controls the log file belongs in the web server data structure.
   Having two locks opens the possibility of ordering problems.  Having just
   one eliminates that issue.

Only if your logging routines need to get at the rest of the web
server data structures.  If your logging routines are self-contained,
the lock ordering issue is trivial and needn't even be mentioned --
you could factor logging out into another library, like C stdio.

(C stdio streams have locks too -- but you don't usually notice, even
if you call printf while you hold some pthread_mutex, because you
~never have to write code that runs with the stdio stream locked.)

   > 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].

   Yes, but I would certainly label these cases "trivial recursion."

Yep, that's what I meant.