> From: Taylor R Campbell <campb...@mumble.net> > Date: Mon, 2 Mar 2015 23:54:09 +0000 > > Date: Mon, 2 Mar 2015 16:34:41 -0700 > From: Friar Puck <p...@birchwood-abbey.net> > > OK. The without-interrupts in hashtb.scm are actually spelled > "with-table-locked". I replaced them with "without-interruption". > The critical sections could probably be narrowed if aborts are now the > sole concern. > > I'm not sure there's actually much narrowing to be had there.
OK, you made me look. 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/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. 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? Many operations could move a functional rehash out of their critical sections, making the sections really tiny. These may be nits. I only mentioned them because, generally, I expect the critical sections we need to keep things consistent to be larger, sometimes much larger, than sections in which we only reveal results without-interruption. > I also serialized access to the population of address hash tables. > There was the tiniest room for a race. It took some cold load > frobination, but I implemented a "serial population" in prop1d.scm to > use in hashtb.scm, geneqht.scm and wherever. > > Why not just cover every population with a mutex? They're not > performance-critical objects, and they are almost always global > databases. 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. > I don't see a need to eliminate STRING-HEAD!. It disables interrupts > only to block the GC, not other threads: the string can't be shrunk by > the GC while we're doing STRING-HEAD!. OK. I guess it just rubs me wrong, especially after I found it leaving holes in the heap, and then found I could remove it so easily. _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
