Re: [MIT-Scheme-devel] Symmetric MultiProcessing

[Friar Puck]

> From: Taylor R Campbell <address@hidden>
> Date: Tue, 3 Mar 2015 20:50:54 +0000
> 
>    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.

Then it shouldn't call maybe-shrink-table! and cons a shorter vector
:-(but not one bucket pair).  If we cons bucket lists too (get more
functional!) blessings will follow.  Is this not a tenet of our faith?

>    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!.

What goes kaboom if it is interrupted?  If the user would notice an
inconsistency after an abort, perhaps the user needed to apply
without-interrupts (or already has!).  If it is the table operations
themselves that are thuswise borked, perhaps without-interruption
needs to be in set-key&datum-ephemeral-entry-datum!.  It does NOT need
to be where with-table-locked was, in method:modify!.  Many table
types just do not need it.

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

I DO assume the hardware will be coherent enough that word-size
reads/writes are atomic/uninterruptible.  Thus without-interruption
sections can get small enough to vanish.  Are we all cool with
that?

Assuming word-size atomic writes, set-ephemeron-datum! is just an
atomic primitive-object-set! followed by a reference barrier (what the
what? and is the test for the #f key just an optimization???).  An
interrupt anywhere in there is no disaster, yes?

>    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.

That would be a problem except that without-interruption is applied
when needed, in rehash-table!.  I was referring to rehashes occurring
in maybe-grow-table! and maybe-shrink-table!, which are called inside
the former with-table-locked sections, at the end of many operations:
hash-table/clean!, set-hash-table/rehash-threshold!,
set-hash-table/rehash-size!, hash-table/put!, hash-table/modify!,
hash-table/remove! and even hash-table/count (via rehash-table!).

I was originally just pointing out that my query-replace of
"(with-table-locked table..." with "(without-interruption ..." was
ham-handed and hashtb.scm probably deserved better.

I was also just trying to air the issues, so I thank you for the
feedback.

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

I didn't want to force serialization on all populations, much less
serialize all operations on all populations.