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

[Micah Brodsky]

IMO, you’re both right. With a simple monitor architecture, recursive re-entry is as legitimate as having exposed APIs that are also useful internally as building blocks for more complex transactions. Simple solutions for simple problems. In a more complex architecture, you want to keep closer control over what’s held when and crash proactively if your presumptions are violated e.g. by re-entry. Taylor’s latest patch lets the dev choose, which is how it should be!

 

(Mind, locks are still horrible, horrible things. The first thing I usually do is write a better set of abstractions suited to the problem at hand. …maybe I should package some of those. ;)

 

--Micah

 

From: address@hidden [mailto:address@hidden On Behalf Of Arthur A. Gleckler
Sent: Tuesday, June 09, 2015 1:05 AM
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:

 

   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.

 

Still, when logging is used in the web server, the lock needs to reside somewhere.  It shouldn't have to be passed around separately from the web server, so I just incorporated it into the web server.

 

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

 

Interesting.

 

I'm not sure what interactions might happen at the Scheme level, though.