[Techtalk] Theory vs. practice

[Julie]

Val Henson wrote:
> 
> On Wed, Jan 16, 2002 at 12:44:38AM -0600, Julie wrote:
> > Val Henson wrote:
> > >
> > > :) I'm sorry - I realize that many of the best kernel developers don't
> > > even post on l-k.  When you see people who are pushing for (and have
> > > written the patches for) a preemptive Linux kernel, and these selfsame
> > > people don't understand priority inversion or think it is a
> > > problem... That's when I *fear* for the future of Linux.
> >
> > So ... do these people even understand serialization?  Because
> > life inside a pre-emptible kernel gets really =weird=.
> 
> See, that's the scary part.  If the preemptive kernel implementers
> said, "I understand this problem, and here's why it doesn't apply to
> us," I wouldn't be so concerned.  Instead, they're saying "That
> problem doesn't apply to us," without explanation.  So I'm forced to
> conclude that they don't understand what really happens in a
> preemptive kernel.
> 
> To my great relief, Alan Cox and Arjan van de Ven and some other folks
> are demonstrating that they understand the problem. :)

Almost sounds like an alphabetic order thing ;-)

> > I did a one-hour brown bag at work on kernel programming.  I
> > described the AIX kernel as "not just multi-threaded, but
> > =insanely= multi-threaded".
> 
> And that's the other annoying thing about some (not all) Linux
> developers.  "Just because <some OS> did it wrong doesn't mean Linux
> can't do it right."  I agree with that, but I also think you need to
> have a good argument for *why* and *how* Linux is going to do things
> right.  For example, a preemptive kernel: Solaris and IRIX implemented
> it and paid a huge price in code complexity.  Please, do tell how
> Linux is going to implement it differently?

Once upon a time, thousands of years ago, AIX was much smaller
and simpler.  And still very pre-emptible.

It isn't hard to get it right, but you have to know what you're
doing exactly where you're doing it =and= just how long you
plan to be doing it.  For example, that little old lady shouldn't
be counting her pennies while holding a write lock on, say, the
system file table.

My experience is that most people can't keep track of how many
different interactions there are, or are possible, with other
parts of the system.  So they get very blindered.  They also get
ordering wrong.  For example, if you're going to open a file,
do all your damned disk I/O operations before you go get an
exclusive lock on some system-wide resource.  I've seen
programmers who get very linear in their thinking

	get exclusive lock on some table
	if desired object not in table then
		read object from disk
		build object entry
		add entry to table
	endif
	perform operation on object in table
	release exclusive lock on table

Which is all very well and good (and boring ;-), but also very
prone to grinding the system to a halt.  More better is

	get shared lock on some table
	lookup object in table
	release shared lock on table

	if object wasn't found then
		read object from disk
		build object entry

		get exclusive lock on table
		if desired object is now in the table then
			discard new object
		else
			add new object to table
		endif
		release exclusive lock on table
	endif
	perform operation on object in table

No one has to wait for the disk I/O and that exclusive lock is
only held for as long as it takes to re-search and update the
table.
-- 
Julianne Frances Haugh             Life is either a daring adventure
jockgrrl at austin.rr.com                 or nothing at all.
					    -- Helen Keller