Re: Intel details future Larrabee graphics chip


"Nick Maclaren" <nmm1@xxxxxxxxxxxxx> wrote in message news:g7un01$r1g$1@xxxxxxxxxxxxxxxxxxxxxxx

In article <A2Bok.93299$tc1.77407@xxxxxxxxxxxxx>,
"Wilco Dijkstra" <Wilco.removethisDijkstra@xxxxxxxxxxxx> writes:
|>
|> > |> Most "safe" languages have these properties unfortunately. For example runtime
|> > |> checks require complex exception support (Pascal just terminates the program
|> > |> when a check fails, which is NOT safe behaviour).
|> >
|> > That myth is why so few modern compilers do any checking. It is utterly
|> > and completely false.
|>
|> I'm not sure what myth you're alluding to, but you're mistaken if you think
|> that it is enough to just *detect* errors without any further action. Automatic
|> checks give a misleading feeling of safety as they focus only on detection
|> with little effort put into prevention and mitigation.

Eh? Automatic checks with a hard failure ensure that you can't have
a nice, cosy feeling of safety when your program's execution is actually
completely undefined!

Hard failures are fine while you're developing and debugging, but they are
not in the field (eg. Ariadne).

Automatic checks can only find a small proportion of the problems that occur
in real software. That doesn't mean they are totally worthless (although
null pointer checks clearly are, as are overflow checks in most cases).
However *explicit* pre/post condition and other consistency checks are far
more important, as is taking appropriate action if such a check fails.

|> However almost all systems do not have such elaborate backup systems,
|> and so have to do a lot more to ensure an acceptable level of service.
|> Shutting down and rebooting is certainly an option, but it does require
|> saving all work, checking data integrity and rebooting into the same
|> context. Even Office nowadays does this - it is a lot better than losing
|> all your unsaved work and context, however it is still not good enough.

So corrupting your data is BETTER than losing your current work?
Because that IS what you are saying - those are the only two options
you get for most errors - you really DON'T know what effect ignoring
or suppressing the erro will have.

I never said that, read again what I wrote. Crashing is equivalent to
corrupting and losing your work. Continuing after resolving the failure
and getting back into a consistent state is clearly the better option.

|> > To take one example, would you rather a passenger aircraft controls
|> > jammed for a second while switching systems, or opened the air brakes
|> > on the left wing to full?
|>
|> That is not how safety critical systems work. Firing an airbag or brakes by
|> accident is something that is designed to be pretty much impossible via a
|> combination of software and hardware features.

When you carry on after a serious error, the failure is at least as
likely to cause the software part of those safety mechanisms to fail
as anything else.

Not if the safety mechanisms were properly designed. Software failures
tend to be local and rarely cause widespread corruption.

Wilco


.

Relevant Pages

  • Re: Intel details future Larrabee graphics chip
    ... |>> |> when a check fails, ... |>> That myth is why so few modern compilers do any checking. ... cosy feeling of safety when your program's execution is actually ... When you carry on after a serious error, the failure is at least as ...
    (comp.arch)
  • Re: Saturn V
    ... for vehicle or mission failure depends on the combined risks for the ... The practice of risk analysis is not ... Managing and understanding risks for better safety has a long history ...
    (sci.space.history)
  • Re: Dont forget the pre-trip
    ... A bearing failure can happen with no warning; depending on how it fails, ... A set of rear dual tires and wheels came off a passing semi and struck ...
    (misc.transport.trucking)
  • Re: Forths Dilemma
    ... Many SIL-certified safety systems have 1oo3 or 2oo3 CPUs ... So I guess that in case of software failure your ... The hardware circuitry of the Pulse Maintained Relays is such that failure ... circuitry will result in the relay being de-energised. ...
    (comp.lang.forth)
  • Re: Number of digits in factorial
    ... give the number of decimal digits in n! ... the first n for which fails may be difficult to ... is infinite. ... reason for failure. ...
    (sci.math)