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

[Taylor R Campbell]

   Date: Tue, 9 Jun 2015 01:29:20 -0400
   From: "Micah Brodsky" <address@hidden>

   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!

I maintain it would be better to have separate abstractions for
applications requiring recursion so that nobody is tempted to try
WITH-THREAD-MUTEX-LOCKED for a lock that is intended to be
nonrecursive.

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

There is an implementation of Concurrent ML for MIT Scheme and others
at

http://mumble.net/~campbell/darcs/scheme-cml

which includes multiplexed waits on synchronous channels.  If any of
you are interested in using it, feel free to ask me questions -- or if
you'd like to pick it up and extend it, perhaps along the lines of the
TODO at <http://mumble.net/~campbell/tmp/TODO.scheme-cml>.

But simply throwing out objects called `mutexes' does not absolve you
of the need to design the conservation laws that mutexes represent in
a complex program.

If you adopt the Erlang dogma of storing all state `immutably' in
separate processes, then each process's state has conservation laws
implied by the behaviour of that process.  If you want conservation
laws that apply to the state of two processes in aggregate, you likely
need to have an arbiter process to enforce them -- and in so doing,
you've just created three locks and a lock order between them.