Date: Tue, 9 Jun 2015 01:29:20 -0400 From: "Micah Brodsky" <micah...@csail.mit.edu>
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. _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
