[gambit-list] Suggesting silently released mutexes

Christian Jaeger christian at pflanze.mine.nu
Fri May 23 23:17:31 EDT 2008

Hello Marc

Gambit's mutexes are usually nice in that they are in state "abandoned" 
when the thread which locked them is terminated. Subsequent mutex-lock! 
calls throwing abandoned-mutex exceptions makes sense when the mutexes 
are protecting data structures, since those are then in an unsafe state 
and need manual inspection anyway. But there are cases where Scheme 
mutexes are to be used where they are protecting from entry by multiple 
Scheme threads to regions which are executed atomically; for example, 
foreign C code which does need to be protected against usage by multiple 
threads (i.e. requires consistency in it's own C data structures), but 
is also using Scheme callbacks for e.g. allocation of return values. 
This requires a Scheme mutex to prevent (even current) Gambit from other 
Scheme threads entering the C code while the latter is running the 
callback; but termination of a Scheme thread will never leave any data 
in inconsistent state, since the data mutation is done in C which will 
(at least currently) not be interrupted by the termination of a Scheme 
thread. (All that can happen is that a C call frame will remain on the C 
stack if the termination happens to be during the callback, which is 
just a (rare) leak which is unavoidable anyway.)

In those cases, the abandoned-mutex exception is then just a 
disturbance. I've written a crude wrapper around the normal mutex 
operations which solves the disturbance:


But it may make sense to offer such "safe" mutexes in the core (I've 
called them "process-mutex" in analogy to filehandle-based locks in Unix 
which are released when a Unix process is killed).


More information about the Gambit-list mailing list