Andrew Lentvorski wrote:
It is. It's called double checked locking. And it fails except under
specific circumstances involving the underlying read/write consistency.
Err, no. At what point do you think it fails? There's no locking at
all, so it's not double-checked locking.
If you actually have a sequence of events that you think would lead to
failure, I'd like to hear it, because I'd like this code to be right.
In addition, the election process is subject to "livelock". If two
processes are each trying to get elected quickly, they will starve each
other.
Um, no. Each process only writes to "Nominated" at most once. Hence,
you can't livelock. Whoever wrote last to "Nominated" gets elected, once
everyone sees it. If the write propagates reliably in five seconds, then
only the machines all started in those first five seconds will write to
the Nominated file, and whoever writes last wins within another five or
ten seconds or so. None of the other files have the possibility of being
written by more than one process, so I don't see where any livelock
could come into play.
The only reason more than one person would ever write to "Nominated" is
if you started two processes so close together that the first write
hadn't propagated to the second before the second started.
As long as the data gets made globally available with decent promptness,
it's pretty efficient (except for the fact, of course, that everything
is polling).
This is the main problem with concurrency--"close enough" isn't.
This is true. You should tell that to the people responsible for the
Linux core, for example. ;-)
--
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
