[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIT-Scheme-devel] Symmetric MultiProcessing
From: |
Taylor R Campbell |
Subject: |
Re: [MIT-Scheme-devel] Symmetric MultiProcessing |
Date: |
Tue, 3 Mar 2015 20:50:54 +0000 |
User-agent: |
IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1.99 |
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.