Subject: Re: splx() optimization [was Re: SMP re-eetrancy in "bottom half" drivers]
To: Daniel Carosone <dan@geek.com.au>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: tech-kern
Date: 06/09/2005 22:34:05
In message <20050610045847.GG892@bcd.geek.com.au>,
Daniel Carosone writes:
>Finally, making smp-safe datastructures doesn't necessarily involve
>locks; there is much research on other primitives and constructions,
>especially from those trying to scale to many-way SMP and other more
>diverse architectures where lock-taking latency kills.
(Mmm, I wonder, did you write that before seeing my preivous message,
or after?)
Yes, there is much published research in lock-free synchronization.
But a good case can be made that only a small fraction of that
research is of practical relevance to real OS implementors for
general-purpose hardware. Much of Herlihy's early work recovers from
contention by copying the entire structure being updated. Other work
assumes CPU-specific features two-address atomic compare-and swap
(m6040 CAS2, I forget the 370 mnemnonic). Or *truly* type-stable
memory. Or papers which assign unit cost to a synchronization
primitive which, if you work it out in bus utilization, ends up being
an n^3 operation. Or researchers who conisder that 68k assembly code
is "a rapid-protoyping language". (Yes, really.)
Don't get me wrong, there *is* a lot of useful, applicable work. But
for someone new to that field, it can sometimes require a nontrivial
(e.g., doctoral-candidate level) background in computer architecture
or OSes, to quickly figure out which is relevant to architecting a
general-purpose CPU-portable OS; and which isn't.