mit-scheme-devel
[Top][All Lists]
Advanced

[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: Mon, 2 Mar 2015 23:54:09 +0000
User-agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1.99

   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.

   I had just previously re-implemented object-hash with a pair of weak
   tables and a mutex, so it seemed overkill for each table operator to
   also grab and release a mutex.  I am assuming the user will serialize
   operations on hash tables, just like port or string operations.

Yes.

   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.

   BTW, I successfully removed string-head! from the runtime system, but
   then stashed the patch.  If user threads are using strings serially,
   string-head! is no worse than substring-move!(?).

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



reply via email to

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