Re: Spinlock performance improvement proposal

Lincoln Yeoh wrote:
>
> At 10:02 AM 9/27/01 -0400, mlw wrote:
> >"D. Hageman" wrote:
> >> I agree with everything you wrote above except for the first line. My
> >> only comment is that process boundaries are only *truely* a powerful
> >> barrier if the processes are different pieces of code and are not
> >> dependent on each other in crippling ways. Forking the same code with the
> >> bug in it - and only 1 in 5 die - is still 4 copies of buggy code running
> >> on your system ;-)
> >
> >This is simply not true. All software has bugs, it is an undeniable fact.
> Some
> >bugs are more likely to be hit than others. 5 processes , when one process
> hits a
> >bug, that does not mean the other 4 will hit the same bug. Obscure bugs kill
> >software all the time, the trick is to minimize the impact. Software is not
> >perfect, assuming it can be is a mistake.
>
> A bit off topic, but that really reminded me of how Microsoft does their
> forking in hardware.
>
> Basically they "fork" (cluster) FIVE windows machines to run the same buggy
> code all on the same IP. That way if one process (machine) goes down, the
> other 4 stay running, thus minimizing the impact ;).
>
> They have many of these clusters put together.
>
> See: http://www.microsoft.com/backstage/column_T2_1.htm
> >From Microsoft.com Backstage [1]
>
> OK so it's old (1998), but from their recent articles I believe they're
> still using the same method of achieving "100% availability". And they brag
> about it like it's a good thing...
>
> When I first read it I didn't know whether to laugh or get disgusted or
> whatever.

Believe me don't think anyone should be shipping software with serious bugs in
it, and I deplore Microsoft's complete lack of accountability when it comes to
quality, but come on now, lets not lie to ourselves. No matter which god you
may pray to, you have to accept that people are not perfect and mistakes will
be made.

At issue is how well programs are isolated from one another (one of the
purposes of operating systems) and how to deal with programmatic errors. I am
not advocating releasing bad software, I am just saying that you must code
defensively, assume a caller may pass the wrong parameters, don't trust that
malloc worked, etc. Stuff happens in the real world. Code to deal with it.

In the end, no matter what you do, you will have a crash at some point. (The
tao of programming) accept it. Just try to make the damage as minimal as
possible.