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

[Markus:]

Regards,
Markus

From: Arthur A. Gleckler

Sent: Tuesday, June 9, 2015 12:30

To: Taylor R Campbell

Cc: address@hidden

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

‎

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.

 

   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.

Initially, I changed me code that way, but the result was repetitive and ugly.  I revived my own recursive `with-thread-mutex-locked' in a new procedure called `with-thread-mutex-locked-recursive'.  That way, it's at least marked.

I'm prepared to believe that the tradeoff works as you suggest in more complex cases, but in such simple ones as this, it appears to work the other way.

 

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