Stewart Stremler wrote:
Well, eliminating starvation gets trickier.
Not really. You can dedicate one process to (for example) managing the
"token" when nobody else has it. You can avoid starvation if you have a
producer/consumer model that's the synchronization.
In my OddJob distribution system, I have each machine look for a
"Nominated" file. If it's there, it copies it into a file named after
that machine's hostname. If it's not there, it copies its own hostname
into the "Nominated" file. The machine that is nominated watches for the
file to change for some number of seconds (like, it has to go 30 seconds
without change), and for all other hostnamed files to contain the same
thing as the Nominated file. When that's the case, the machine that's
nominated copies its name into "Elected". At that point, all the other
machines delete their own names, at which point the elected master
deletes "Nominated", and away everyone goes, knowing who is elected.
As long as updated propagate in a small fraction of 30 seconds, it would
seem to be good, as nobody will see the old value and not the new value.
I.e., when one makes a chnage, it then watches for all the others to
acknowlege the change before proceeding.
It's sort of sort of a cooperative token-ring?
What does that mean?
It means "it depends what you mean by token-ring", and it depends on
exactly what you implement. Again, my point was that you don't need
atomic test-and-set transactions to implement locking. The details will
depend on the scheme used.
It's sounding like it's less and less a good general-purpose approach
and more and more a specific-problem approach.
Well, you tailor it for a specific problem. The "general approach" is to
not have more than one process allowed (by the protocol) to write to the
same memory at the same time. This eliminates race conditions and hence
the need for atomic instructions to do locking.
Well, you need atomic reads and writes of memory. That's how you
get the non-corruption of your memory.
It's difficult to imagine how you'd corrupt a single bit.
So while you don't have test-and-set, you still get atomic.
True. You have to read what was written, yes. If asynchronous reading of
memory winds up corrupting the value in that memory, you're pretty
screwed. But then you probably don't have a test-and-set instruction either.
I think they call that an "interrupt disable".
Which is not something you typically have access to in a HLL.
Well, only one, AFAIK.
?
Ada, of course.
--
Darren New / San Diego, CA, USA (PST)
His kernel fu is strong.
He studied at the Shao Linux Temple.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
