[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MIT-Scheme-devel] Symmetric MultiProcessing

From: Friar Puck
Subject: [MIT-Scheme-devel] Symmetric MultiProcessing
Date: Mon, 23 Feb 2015 16:01:13 -0700

> From: Friar Puck <address@hidden>
> Date: Sun, 21 Dec 2014 13:03:25 -0700
> [...]
> Encouraging results are just what SOMEONE needs when going in the ring
> with up to 104(!) possible demons in the guise of without-interrupts.
> And that's just the runtime system.

As The Reformation grinds along, I find that without-interrupts is
used for a couple of reasons.  I am looking for uses intended to make
multiple side-effects "atomic" from the point of view of other
threads, and replacing them with explicit serialization via new thread

The condvar.scm file already serializes its operations, yet still uses
without-interrupts, presumably for another reason.  I am guessing that
the intention is to stave off "aborts" or ANY keyboard interrupt that
could eventually throw and leave globally accessible (by threads other
than The Aborted One) data structures inconsistent.

I have been known to pound with frustration on Ctl-G (repeatedly).
Maybe I'm not the only one.  If Edwin is going to endure such fits
with aplomb, the runtime system it relies on must be wrapping updates
with SOMETHING, if not without-interrupts perhaps
without-keyboard-interrupts (based on with-thread-events-blocked)?
The latter has the advantage that it is easy to see which uses of
without-interrupts have been sorted.  In the end, there will be no
more without-interrupts (except the interesting exception in ffi.scm).

Or without-keyboard-interrupts is just needlessly wordy and adds to
the size of the SMP patches.  In the end, without-interrupts can be
changed to use with-thread-events-blocked, allowing thread switching
where it will do no harm.  Which to choose?

There are other issues involved in this reform and they are all
discussed in the top-level README.txt file of my SMP branch.  For
example, object hash tables now have their own mutex while normal hash
tables (eq and generic) do not.  If you want to have any input into
these choices, please make your suggestions sooner.  If you like
surprises, you can wait until I cry havoc (i.e. "git merge SMP") and
THEN make extraordinarily patient, hopefully detailed suggestions.

Yours in Scheme,

$ git remote add puck git://
$ git fetch puck SMP
$ git checkout puck/SMP
$ more README.txt

If you look at the commit chain you will see commits that are intended
to be squashed into earlier commits.  You can correctly infer that at
least one more rebasing is on offer.  If you want to pitch in, just
say so.  I will push to Savannah a final rebased SMP from which you
can safely branch.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]