[gambit-list] Suggesting silently released mutexes
christian at pflanze.mine.nu
Fri May 23 23:17:31 EDT 2008
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