bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Linus replies. Re: Computer: Can We Make Operating Systems Reliable


From: Christopher Browne
Subject: Re: Linus replies. Re: Computer: Can We Make Operating Systems Reliable and Secure?
Date: Wed, 10 May 2006 15:11:35 GMT
User-agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (linux)

Donnie Jones <donnie@darthik.com> writes:

> Hello,
>
> I am a lurker on this list, but since Tanenbaum got to voice his
> opinion, I figured I would forward on the related reply by Linus.
>
> Link:
> http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=4342&Thread=12&entryID=66630&roomID=11
>
> Excerpt from the post by Linus:
> ********
> The fundamental result of access space separation is that
> you can't share data structures. That means that you can't
> share locking, it means that you must copy any shared data,
> and that in turn means that you have a much harder time
> handling coherency. All your algorithms basically end up
> being distributed algorithms.
>
> And anybody who tells you that distributed algorithms
> are "simpler" is just so full of sh*t that it's not even
> funny.
>
> Microkernels are much harder to write and maintain
> exactly because of this issue. You can do simple
> things easily - and in particular, you can do things where
> the information only passes in one direction quite easily,
> but anythign else is much much harder, because there is
> no "shared state" (by design). And in the absense of shared
> state, you have a hell of a lot of problems trying to make
> any decision that spans more than one entity in the
> system.
> ********
>
> I am very new to kernel development, but I do currently work with
> distributed algorithms and I find Linus argument that microkernels are
> more complex very interesting, what do you guys think?

I "do" database replication (I'm one of the developers for the Slony-I
project; a replication system for PostgreSQL), which is another sort
of "distributed system," and I'd have to generally agree.  We have to
watch out a lot for race conditions that simply don't exist in a
non-distributed system.

Some of our folk had been working on a "Slony-II," which was to be a
multimaster replication system.
http://www.slony2.org/wiki/index.php?title=Main_Page

We gave up; distributed locking turns out to be *WAY* too expensive
for our applications.  Others are still working on it; there's to be a
presentation at O'Reilly's OSCON conference in July:
<http://conferences.oreillynet.com/cs/os2006/view/e_sess/8614>.

I am inclined to mostly agree with Torvalds' comments.  If you can
carefully restrict designs so that you can evade the full complexity
of nasty distributed algorithms, then you may get around this.  But
"full generality" makes it very easy for things to blow up due to
locking getting too expensive, or due to having missed race conditions
you didn't expect...
-- 
output = reverse("gro.mca" "@" "enworbbc")
http://www.ntlug.org/~cbbrowne/slony.html
"Everyone likes flattery, and when you come to Royalty, you should lay
it on with a thick trowel."  -- Benjamin Disraeli on Queen Victoria


reply via email to

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