[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

From: Friar Puck
Subject: Re: [MIT-Scheme-devel] Symmetric MultiProcessing
Date: Tue, 3 Mar 2015 13:14:47 -0700

> From: Taylor R Campbell <address@hidden>
> Date: Mon, 2 Mar 2015 23:54:09 +0000
>    Date: Mon, 2 Mar 2015 16:34:41 -0700
>    From: Friar Puck <address@hidden>
>    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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]