> From: Taylor R Campbell <campb...@mumble.net> > Date: Tue, 3 Mar 2015 20:50:54 +0000 > > Date: Tue, 3 Mar 2015 13:14:47 -0700 > From: Friar Puck <p...@birchwood-abbey.net> > > 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. _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
