Re: [MIT-Scheme-devel] Symmetric MultiProcessing

[Taylor R Campbell]

   Date: Tue, 3 Mar 2015 13:14:47 -0700
   From: Friar Puck <address@hidden>

   The first use of without-interruption is in hash-table/clean!.  I
   don't see the need.  An abort during a cleaning should be harmless.
   Each splice produces a valid bucket.  Only new-size! really needs to
   protect against an abort as it moves bucket pairs from the old table
   to the new.  If it consed new bucket lists, its critical section would
   be small enough to vanish.

HASH-TABLE/CLEAN! probably shouldn't cons.

   Hash-table/modify!'s first critical section contains just
   set-entry-datum!, a single pointer/word write.  Our machine writes
   words atomically, yes?  Can't this section vanish?  I don't think
   clean! nor modify! need to do any interrupt-mask frobnication.

Counterexample: SET-KEY&DATUM-EPHEMERAL-ENTRY-DATUM!.

Not sure SET-EPHEMRON-DATUM! is guaranteed to be atomic either.

   Hash-table-copy had a with-table-locked around the entire construction
   process.  The bucket list mutation required it.  A more functional
   rehash, re-constructing the bucket lists as well as the vector, would
   obviate interrupt-mask frobnication as well as the kind of lock
   contention that would stall lookups during the copy.  Are we not fond
   of trading off space for speed/contention?

The WITH-TABLE-LOCKED! in HASH-TABLE-COPY looks spurious to me.  Maybe
Chris knows better.

   Many operations could move a functional rehash out of their critical
   sections, making the sections really tiny.

I don't see anywhere that COMPUTE-HASH! is called while interrupts are
blocked.

   I considered that, but the abstraction seemed generally useful (and
   widely neglected), Scheme mutexes are cheap to create, and more are
   better, contention-wise.  At this point, serial-populations are
   implemented and tested.

Hmm?  I don't understand.  Why create two separate abstractions?  Just
protect all protections by a mutex by default, inside the population
abstraction.