View mode: basic / threaded / horizontal-split · Log in · Help
April 20, 2005
Re: Robust, fault-tolerant software is easier to write with D than C++. Or is it? [was: Re: recoverable and unrecoverable errors or exceptions]
Looks like a good page to be on too.  :)

TZ

"Walter" <newshound@digitalmars.com> wrote in message news:d3q3jv$1q48$2@digitaldaemon.com...
>
> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
> news:d3pt4s$1lbb$1@digitaldaemon.com...
> > My analogy with systems on an airplane is that the code that realized a
> > subsystem failed and decided to shut that particular subsystem down
> > effectively "caught" the problem in the subsystem. The same approach
> applies
> > to a piece of software that catches a problem in a subsystem and deals
> with
> > it. Just as an error in a subsystem on an airplane doesn't shut down the
> > entire airplane so an error in a subsystem in a piece of software should
> > shut down the entire software. I agree the level of safety and reduncancy
> is
> > much higher in an airplane but my argument was that *something* on that
> > airplane realized the subsystem was in error and dealt with it.
>
> Ok. We're on the same page, then.
>
>
April 20, 2005
Re: Robust, fault-tolerant software is easier to write with D than C++. Or is it? [was: Re: recoverable and unrecoverable errors or exceptions]
"TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message 
news:d44p6j$2c2a$1@digitaldaemon.com...
> Looks like a good page to be on too.  :)
>
> TZ
>
> "Walter" <newshound@digitalmars.com> wrote in message 
> news:d3q3jv$1q48$2@digitaldaemon.com...
>>
>> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
>> news:d3pt4s$1lbb$1@digitaldaemon.com...
>> > My analogy with systems on an airplane is that the code that 
>> > realized a
>> > subsystem failed and decided to shut that particular subsystem 
>> > down
>> > effectively "caught" the problem in the subsystem. The same 
>> > approach
>> applies
>> > to a piece of software that catches a problem in a subsystem 
>> > and deals
>> with
>> > it. Just as an error in a subsystem on an airplane doesn't shut 
>> > down the
>> > entire airplane so an error in a subsystem in a piece of 
>> > software should
>> > shut down the entire software. I agree the level of safety and 
>> > reduncancy
>> is
>> > much higher in an airplane but my argument was that *something* 
>> > on that
>> > airplane realized the subsystem was in error and dealt with it.
>>
>> Ok. We're on the same page, then.

I don't think they are on the same page, because that would assume 
that the barriers between valid and invalid code within a process 
are analogous to those between separate redundant computer systems 
with external arbitration mechanisms in an aircraft control system. 
Since the former have the extreme intimacy of a shared address space 
and thread(s) of execution, and the latter are (as far as I can 
guess, as I do not know) connected only by physical actuators and a 
shared power supply (maybe?), this analogy cannot hold.

Yes, it's conceivable that one of the redundant computer systems on 
the aircraft could, in principle, cause, in its death throes, 
sufficient perturbation of the power supply of one of the other ones 
as to effect a catatrophic failure, but that is, I suggest, within 
the limit of acceptable risk. ;)

Anyway, I've foresworn further comment on the issue until my 
article's published, so I'll shut up again. Sorry. ;-)
April 20, 2005
Re: recoverable and unrecoverable errors or exceptions
Yes, 64 bit ints were standardized long before processors with a 16 bit data bus became common, and therea re many reasons why it would be a bad idea to try to "replace" that standard at this time.

That said, however, I don't think there would be anything wrong with adding a new "enhanced" integer data type, that includes thing like a "not an integer" value, as well as other enhancements.

The trouble, I think, would be getting enough people to agree on a "standard" enhanced integer type.  I have, for example, made data types with only integer magnitude, but a floating point angle from the "positive" vector direction to the data's location within the complex number plain.  Very useful, but not something "everyone" would want.

I've also made "nearly integer" data types, such as a large range of integer values with a small range of floating point positions, to expand the range of valid numbers within the available precision.

For example, using an exponent value in the range of -3 to 4 representing multiplication of the integer mantissa my 1000 raised to the exponent value can change a signed 32 bit range (-32768..32767) into -0.000008192 .. 0.000008191, -0.008192 .. 0.008191, -8.192 .. 8.191, -8192 .. 8191, -8192000 .. 8191000, -8192000000 .. 8191000000, -8192000000000 .. 8191000000000, -8192000000000000 .. 8191000000000000, which can be handy with certain type of statistical data, but probably isn't much use for anything else.  Thange the base of the exponent from 1000 ro 100, or 16, and which uses are reasonable also changes... so what is best turns out to be strictly a matter of opinion.

Yes, a useful extended int, or pseudo-int be agreed on by enough people that it could become "a standard" eventually, but I don't see it as likely that it would ever replace the current standard because it simpler is usually more universal... and the existing standard for integer representations of any power of two number of binary digits is so simple that it's almost "generic" in nature.

TZ


"Walter" <newshound@digitalmars.com> wrote in message news:d3v6kb$2ucq$1@digitaldaemon.com...
>
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
> news:4262E94B.400@nospam.org...
> > Say we decide that (int64_max_value - 1) is an official NAN-INT. And for
> > the signed, (int64_max_value/2 -1) would be the value.
> >
> > Questions:
> >
> > 1) Can anybody give a thoroughly solid reason why we _cannot_ skip using
> > these particular values as "NAN"s? (In other words, can someone pretend
> > that we really (even in theory) will actually need _all_ 64bit integer
> > values in production code?)
>
> We can't. 64 bit ints are often used, for example, to implement fixed point
> arithmetic. Furthermore, NANs work best when the hardware is set up to throw
> an exception if they are used.
>
> > 2) Could it be possible to persuade the "C99 kings" to adopt this
> practice?
>
> I just think that no way would that ever happen.
>
> > 3) If so, could we/they persuade to have chip makers implement hardware
> > traps for these values? (As today null checks and of/uf are done?)
>
> The hardware people could do it by adding an "uninitialized" bit for each
> byte, much like the parity bit. Then, a hardware fault could be generated
> when an "uninitialized" memory location is read. This won't break existing
> practice.
>
> > 4) Is it possible at all to have the Old Farts, who hold the keys to
> > Programming World, to become susceptible to our demands?
>
> LOL.
>
>
April 20, 2005
Re: Robust, fault-tolerant software is easier to write with D than C++. Or is it? [was: Re: recoverable and unrecoverable errors or exceptions]
Well, that is one way of looking at it.  What I see though, is that they agree on the princible of what "should" be done, to the extent that it is possible to do.  I also agree with the way Ben put it, because there is a definate parallel there.

For example, just like parts of a running program share the same address space, the parts of  an aircraft in flight also share the same sky.  For that matter, different programs on the same computer also share the same address space at least on a hardware level, and likewise any number of distinct pieces of flying hardware may be carrying passangers and such around in the same sky at the same time.

It is, however, possible to designate a "portion" of the sky for a specific aricraft, and a "portion" of the computer's addrerss space for a specific program.  In both cases, there exists the possibility of the assigned boundaries being violated, and in either case, the results can potentially lead to a crash.

With this in mind, remember that while the programmer has little or no control over the nature of the hardware that the program will run on, the aircraft designer also has little or no control over the atmosphere in which thier creation will fly.  As such, both the software engineer and the aricraft engineer are restricted in their ability to add fault tollerance, but there are still things that can be done even within such restrictions.

Microprocessors make mistakes all the time... and I don't mean simply that they make mistakes every so many billion operations.  The whole reason it's so hard for microprocessor designers to keep finding ways to make them smaller, is because their very design is based on the idea that electrons will go where they want whether we like it or not.

Make it a little easier for electrons to go one way than another way, and more of them will take the easier way.  Meanwhile, a few will take the harder way because those they were repelled by those taking the easier way, and a few will take the harder way because their particular allignment made that way easier for them specifically, and a few will take the harder way simply because "they can" but the chip is designed to take advantage of the "average" action by using excessive redundancy.  As chips get smaller, the amount of redundancy possible in a single electron path decreases substantially, and compensations have to be made.

In other words, if every stray electron that went "the wrong way" crashed the microprocessor that it was traveling through, there wouldn't be time to execute a single hardwired microcode instruction like "fetch" before the chip crashed.

Extreme fault tollerance requires sacrafice though.  You could use hashes and checksums all over the place, and redundantly write every piece of data to multiple memory locations, and periodically back up every piece of data to external storage along with the processor state and so on... but don't expect your program to get anything done while you're still alive to see it because it would be so slow it would pass for frozen.

Looks to me like Walter and Ben have the right idea.  Yes, it may be foriegn to you, but that doesn't mean it won't work.  Give it a chance... see how it works out.

TZ

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d44q3s$2cmj$1@digitaldaemon.com...
>
> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message
> news:d44p6j$2c2a$1@digitaldaemon.com...
> > Looks like a good page to be on too.  :)
> >
> > TZ
> >
> > "Walter" <newshound@digitalmars.com> wrote in message
> > news:d3q3jv$1q48$2@digitaldaemon.com...
> >>
> >> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
> >> news:d3pt4s$1lbb$1@digitaldaemon.com...
> >> > My analogy with systems on an airplane is that the code that
> >> > realized a
> >> > subsystem failed and decided to shut that particular subsystem
> >> > down
> >> > effectively "caught" the problem in the subsystem. The same
> >> > approach
> >> applies
> >> > to a piece of software that catches a problem in a subsystem
> >> > and deals
> >> with
> >> > it. Just as an error in a subsystem on an airplane doesn't shut
> >> > down the
> >> > entire airplane so an error in a subsystem in a piece of
> >> > software should
> >> > shut down the entire software. I agree the level of safety and
> >> > reduncancy
> >> is
> >> > much higher in an airplane but my argument was that *something*
> >> > on that
> >> > airplane realized the subsystem was in error and dealt with it.
> >>
> >> Ok. We're on the same page, then.
>
> I don't think they are on the same page, because that would assume
> that the barriers between valid and invalid code within a process
> are analogous to those between separate redundant computer systems
> with external arbitration mechanisms in an aircraft control system.
> Since the former have the extreme intimacy of a shared address space
> and thread(s) of execution, and the latter are (as far as I can
> guess, as I do not know) connected only by physical actuators and a
> shared power supply (maybe?), this analogy cannot hold.
>
> Yes, it's conceivable that one of the redundant computer systems on
> the aircraft could, in principle, cause, in its death throes,
> sufficient perturbation of the power supply of one of the other ones
> as to effect a catatrophic failure, but that is, I suggest, within
> the limit of acceptable risk. ;)
>
> Anyway, I've foresworn further comment on the issue until my
> article's published, so I'll shut up again. Sorry. ;-)
>
>
>
April 20, 2005
Re: recoverable and unrecoverable errors or exceptions
You're overlooking the fact that a 2^x bit integer isn't arbitrary like a floating point representation is.  There is no "unused" or "redundant" value within the range of possible bit patterns, because the range of bit patterns "is" the numeric range.  In fact, the signed and unsigned representations are exactly the same except that in the unsigned representation addition of the place value of the high order bit is replaced by subtraction of that same value.

For example, a 2^1 bit signed range has a -2's place, and a 1's place, giving it a range of -2 to +1, while a 2^1 bit unsigned range has a 2's place and a 1's place, giving it a range of 0 to 3.  Double the number of data bits, for a 2^2 bit signed range, and you get has a -8's place, a 4's place, a 2's place, and a 1's place, giving it a range of -8 to +7, while a 2^2 bit unsigned range has an 8's place, a 4's place, a 2's place, and a 1's place, giving it a range of 0 to 15.  The same simple math holds true for any number of data bits, even if it's not an exact power or two, but increasing by anything other than a power of two leaves the representation of bit positions un-uniform.  Likewise, one of the advantages to the straight binary unsigned and 2's compliment binary signed data types is that they are uniform.  No extra information is necessary to interpret them, and no extra steps are necessary before they can be used.

TZ

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:42637A35.50407@nospam.org...
> (Disclaimer: I'm not going to start a war about this. :-) I am however
> interested in pursuing this for a small while.)
>
> Walter wrote:
> > "Georg Wrede" <georg.wrede@nospam.org> wrote in message
> > news:4262E94B.400@nospam.org...
> >
> >> Say we decide that (int64_max_value - 1) is an official NAN-INT.
> >> And for the signed, (int64_max_value/2 -1) would be the value.
> >>
> >> Questions:
> >>
> >> 1) Can anybody give a thoroughly solid reason why we _cannot_ skip
> >> using these particular values as "NAN"s? (In other words, can
> >> someone pretend that we really (even in theory) will actually need
> >> _all_ 64bit integer values in production code?)
> >
> > We can't. 64 bit ints are often used, for example, to implement fixed
> > point arithmetic. Furthermore, NANs work best when the hardware is
> > set up to throw an exception if they are used.
>
> One could argue that if someone uses (64bit) fixed point arithmetic in a
> field where there is a risk for approaching (our newly invented NAN,
> i.e. int64_max_value - 1) illegal values, then one should be using
> 128bit for that particular purpose instead anyway. (Similar holds for
> signed, too.)
>
> And, that actually is the whole problem of my suggestion. I expect it to
> be monstrously difficult to get "them" to see, that this is a valid idea
> -- now that we suddenly have "very big" integer types at our disposal.
>
> One could use the exact same arguments against "wasting" the bit
> patterns of floating NANs. (And there are truckloads of individual bit
> patterns wasted there!)
>
> ----
>
> To implement this, all we need are two things:
>
> 1) A new fetch instruction that traps this particular bit pattern in
> hardware. (I estimate, on a 64bit CPU, this should take less than 500
> gates -- pretty small compared to some of the other "new" (and IMHO less
> pressing) features.)
>
> 2) Compiler industry to agree to use this whenever we are fetching this
> as an rvalue. (The "regular" fetch would still exist, for all other
> purposes (i.e. when the 64bit entity represents whatever else than a
> 64bit int)).
>
> And while we're at it, of course the same for 128bit ints.
>
> The compiler would use the "new" fetch only where it does not know for
> sure that the variable has been initialised. So, for example loops would
> be free to wrap around. (Not that I'd want them to.)
>
> -----
>
> So, technically this would be trivial and cheap to implement. All we
> need is the will to do it.
>
> That will has to be aroused somehow. Maybe Walter or Matthew could take
> this up in CUJ, or Dr.Dobb's? -- I'd even be happy to assist in the
> writing, or countering the counter arguments you two might get! (The
> baseball bat.)
>
> <pr-talk-mode>
>
> You'd get some extra fame for raising hell about this, too. No matter
> which side wins at the end. And all that fame is needed the day we start
> pushing D with a vengeance.
>
> Or maybe I should get Andy Koenig raving about this instead?
>
> </pr-talk-mode>
>
> This is an important issue, and (as so many times in history) when the
> means to do something about it become only gradually possible, it often
> is unduely hard to get everybody to see that "hey, we can already do it".
>
> >> 2) Could it be possible to persuade the "C99 kings" to adopt this
> >> practice?
> >
> > I just think that no way would that ever happen.
> >
> >> 3) If so, could we/they persuade to have chip makers implement
> >> hardware traps for these values? (As today null checks and of/uf
> >> are done?)
>
> Oh, and incidentally, I've figured out how to extend this to 128bit,
> 256bit, etc. on 64bit machines.
>
> > The hardware people could do it by adding an "uninitialized" bit for
> > each byte, much like the parity bit. Then, a hardware fault could be
> > generated when an "uninitialized" memory location is read. This won't
> > break existing practice.
>
> Way too complicated.
>
> Oh, and about practice: we wouldn't break any existing code
> _that_is_not_broken_already_.
>
> For this new setup to break a single program:
>
> First, somebody has to be un-rigorous about initialising his variables,
> second, the guy has to be operating on values pretty near wrap-around.
> Now, I do see that used, but only for chip testing, or other very
> special purposes. (And somebody else doing uint math relying on
> underflow for home-made "temporary" signed math ought to be shot anyway.)
>
> Besides, this would of course be trappable and quenchable. :-)
>
> If not (gasp) also switchable with a pragma.
>
> >> 4) Is it possible at all to have the Old Farts, who hold the keys
> >> to Programming World, to become susceptible to our demands?
> >
> > LOL.
>
> I've had ministers of the Cabinet do what I want. It's just a matter of
> making them see.
>
> And the thing to see here is in it's entirety: 64bit is suddenly so big
> that we really and honestly can actually _afford_ to waste a single
> value. -- Which never has happened before (with 32, 16, 8bits).
April 20, 2005
Re: Robust, fault-tolerant software is easier to write with D than C++. Or is it? [was: Re: recoverable and unrecoverable errors or exceptions]
I applaud your dedication to painting a picture of unalloyed 
fraternity, but your argument is plasmaware.

   "It is, however, possible to designate a "portion" of the sky 
for a specific aricraft, and a "portion" of the computer's addrerss 
space for a specific program"

You're not even correctly addressing my point, since the analogous 
construct would be:

   "a "portion" of the computer's address space for a 
_subcomponent_ of a specific program"

That is _at best_, as any programmer will tell you, 'not currently 
realistic'.

Anyway, I'm not getting into it any further, as being insulting 
isn't good for anyone, and constantly going round the same old 
houses of misapprehension is tiring, to say the least.


"TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message 
news:d44uj9$2fqg$1@digitaldaemon.com...
> Well, that is one way of looking at it.  What I see though, is 
> that they agree on the princible of what "should" be done, to the 
> extent that it is possible to do.  I also agree with the way Ben 
> put it, because there is a definate parallel there.
>
> For example, just like parts of a running program share the same 
> address space, the parts of  an aircraft in flight also share the 
> same sky.  For that matter, different programs on the same 
> computer also share the same address space at least on a hardware 
> level, and likewise any number of distinct pieces of flying 
> hardware may be carrying passangers and such around in the same 
> sky at the same time.
>
> It is, however, possible to designate a "portion" of the sky for a 
> specific aricraft, and a "portion" of the computer's addrerss 
> space for a specific program.  In both cases, there exists the 
> possibility of the assigned boundaries being violated, and in 
> either case, the results can potentially lead to a crash.
>
> With this in mind, remember that while the programmer has little 
> or no control over the nature of the hardware that the program 
> will run on, the aircraft designer also has little or no control 
> over the atmosphere in which thier creation will fly.  As such, 
> both the software engineer and the aricraft engineer are 
> restricted in their ability to add fault tollerance, but there are 
> still things that can be done even within such restrictions.
>
> Microprocessors make mistakes all the time... and I don't mean 
> simply that they make mistakes every so many billion operations. 
> The whole reason it's so hard for microprocessor designers to keep 
> finding ways to make them smaller, is because their very design is 
> based on the idea that electrons will go where they want whether 
> we like it or not.
>
> Make it a little easier for electrons to go one way than another 
> way, and more of them will take the easier way.  Meanwhile, a few 
> will take the harder way because those they were repelled by those 
> taking the easier way, and a few will take the harder way because 
> their particular allignment made that way easier for them 
> specifically, and a few will take the harder way simply because 
> "they can" but the chip is designed to take advantage of the 
> "average" action by using excessive redundancy.  As chips get 
> smaller, the amount of redundancy possible in a single electron 
> path decreases substantially, and compensations have to be made.
>
> In other words, if every stray electron that went "the wrong way" 
> crashed the microprocessor that it was traveling through, there 
> wouldn't be time to execute a single hardwired microcode 
> instruction like "fetch" before the chip crashed.
>
> Extreme fault tollerance requires sacrafice though.  You could use 
> hashes and checksums all over the place, and redundantly write 
> every piece of data to multiple memory locations, and periodically 
> back up every piece of data to external storage along with the 
> processor state and so on... but don't expect your program to get 
> anything done while you're still alive to see it because it would 
> be so slow it would pass for frozen.
>
> Looks to me like Walter and Ben have the right idea.  Yes, it may 
> be foriegn to you, but that doesn't mean it won't work.  Give it a 
> chance... see how it works out.
>
> TZ
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message 
> news:d44q3s$2cmj$1@digitaldaemon.com...
>>
>> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message
>> news:d44p6j$2c2a$1@digitaldaemon.com...
>> > Looks like a good page to be on too.  :)
>> >
>> > TZ
>> >
>> > "Walter" <newshound@digitalmars.com> wrote in message
>> > news:d3q3jv$1q48$2@digitaldaemon.com...
>> >>
>> >> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
>> >> news:d3pt4s$1lbb$1@digitaldaemon.com...
>> >> > My analogy with systems on an airplane is that the code that
>> >> > realized a
>> >> > subsystem failed and decided to shut that particular 
>> >> > subsystem
>> >> > down
>> >> > effectively "caught" the problem in the subsystem. The same
>> >> > approach
>> >> applies
>> >> > to a piece of software that catches a problem in a subsystem
>> >> > and deals
>> >> with
>> >> > it. Just as an error in a subsystem on an airplane doesn't 
>> >> > shut
>> >> > down the
>> >> > entire airplane so an error in a subsystem in a piece of
>> >> > software should
>> >> > shut down the entire software. I agree the level of safety 
>> >> > and
>> >> > reduncancy
>> >> is
>> >> > much higher in an airplane but my argument was that 
>> >> > *something*
>> >> > on that
>> >> > airplane realized the subsystem was in error and dealt with 
>> >> > it.
>> >>
>> >> Ok. We're on the same page, then.
>>
>> I don't think they are on the same page, because that would 
>> assume
>> that the barriers between valid and invalid code within a process
>> are analogous to those between separate redundant computer 
>> systems
>> with external arbitration mechanisms in an aircraft control 
>> system.
>> Since the former have the extreme intimacy of a shared address 
>> space
>> and thread(s) of execution, and the latter are (as far as I can
>> guess, as I do not know) connected only by physical actuators and 
>> a
>> shared power supply (maybe?), this analogy cannot hold.
>>
>> Yes, it's conceivable that one of the redundant computer systems 
>> on
>> the aircraft could, in principle, cause, in its death throes,
>> sufficient perturbation of the power supply of one of the other 
>> ones
>> as to effect a catatrophic failure, but that is, I suggest, 
>> within
>> the limit of acceptable risk. ;)
>>
>> Anyway, I've foresworn further comment on the issue until my
>> article's published, so I'll shut up again. Sorry. ;-)
>>
>>
>>
>
>
April 20, 2005
Re: Robust, fault-tolerant software is easier to write with D than C++. Or is it? [was: Re: recoverable and unrecoverable errors or exceptions]
It's not meant as an argument at all, but rather as a statement of opinion from my perspective.
My point is exactly that...
there are different perspectives.
Yours is one.

As for your statement that I was incorrectly addressing your point by speaking of airplains and programs,
you may want to consider the fact that I was attempting to address the bigger picture, since the smaller sub-picture is obviously a part of it.
I didn't think it necessary to mention that within each airplane are it's parts,
and each part occupies a subset of the space that the airplane occupies,
or the fact that those parts are made of materials and/or sub-parts which are in turn made of materials and/or sub-parts or how such parts and sub-parts interact.
The fact remains that it is a reasonable analogy whether or not any specific person understands the connection or sees the parallel.

You're obviously an intellegent person, but...
you don't know "everything" so your argument that my argument is plasmaware can't have taken into account my knowledge or experiences that you lack awareness of.

TZ

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d450cf$2il5$1@digitaldaemon.com...
> I applaud your dedication to painting a picture of unalloyed
> fraternity, but your argument is plasmaware.
>
>     "It is, however, possible to designate a "portion" of the sky
> for a specific aricraft, and a "portion" of the computer's addrerss
> space for a specific program"
>
> You're not even correctly addressing my point, since the analogous
> construct would be:
>
>     "a "portion" of the computer's address space for a
> _subcomponent_ of a specific program"
>
> That is _at best_, as any programmer will tell you, 'not currently
> realistic'.
>
> Anyway, I'm not getting into it any further, as being insulting
> isn't good for anyone, and constantly going round the same old
> houses of misapprehension is tiring, to say the least.
>
>
> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message
> news:d44uj9$2fqg$1@digitaldaemon.com...
> > Well, that is one way of looking at it.  What I see though, is
> > that they agree on the princible of what "should" be done, to the
> > extent that it is possible to do.  I also agree with the way Ben
> > put it, because there is a definate parallel there.
> >
> > For example, just like parts of a running program share the same
> > address space, the parts of  an aircraft in flight also share the
> > same sky.  For that matter, different programs on the same
> > computer also share the same address space at least on a hardware
> > level, and likewise any number of distinct pieces of flying
> > hardware may be carrying passangers and such around in the same
> > sky at the same time.
> >
> > It is, however, possible to designate a "portion" of the sky for a
> > specific aricraft, and a "portion" of the computer's addrerss
> > space for a specific program.  In both cases, there exists the
> > possibility of the assigned boundaries being violated, and in
> > either case, the results can potentially lead to a crash.
> >
> > With this in mind, remember that while the programmer has little
> > or no control over the nature of the hardware that the program
> > will run on, the aircraft designer also has little or no control
> > over the atmosphere in which thier creation will fly.  As such,
> > both the software engineer and the aricraft engineer are
> > restricted in their ability to add fault tollerance, but there are
> > still things that can be done even within such restrictions.
> >
> > Microprocessors make mistakes all the time... and I don't mean
> > simply that they make mistakes every so many billion operations.
> > The whole reason it's so hard for microprocessor designers to keep
> > finding ways to make them smaller, is because their very design is
> > based on the idea that electrons will go where they want whether
> > we like it or not.
> >
> > Make it a little easier for electrons to go one way than another
> > way, and more of them will take the easier way.  Meanwhile, a few
> > will take the harder way because those they were repelled by those
> > taking the easier way, and a few will take the harder way because
> > their particular allignment made that way easier for them
> > specifically, and a few will take the harder way simply because
> > "they can" but the chip is designed to take advantage of the
> > "average" action by using excessive redundancy.  As chips get
> > smaller, the amount of redundancy possible in a single electron
> > path decreases substantially, and compensations have to be made.
> >
> > In other words, if every stray electron that went "the wrong way"
> > crashed the microprocessor that it was traveling through, there
> > wouldn't be time to execute a single hardwired microcode
> > instruction like "fetch" before the chip crashed.
> >
> > Extreme fault tollerance requires sacrafice though.  You could use
> > hashes and checksums all over the place, and redundantly write
> > every piece of data to multiple memory locations, and periodically
> > back up every piece of data to external storage along with the
> > processor state and so on... but don't expect your program to get
> > anything done while you're still alive to see it because it would
> > be so slow it would pass for frozen.
> >
> > Looks to me like Walter and Ben have the right idea.  Yes, it may
> > be foriegn to you, but that doesn't mean it won't work.  Give it a
> > chance... see how it works out.
> >
> > TZ
> >
> > "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
> > news:d44q3s$2cmj$1@digitaldaemon.com...
> >>
> >> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message
> >> news:d44p6j$2c2a$1@digitaldaemon.com...
> >> > Looks like a good page to be on too.  :)
> >> >
> >> > TZ
> >> >
> >> > "Walter" <newshound@digitalmars.com> wrote in message
> >> > news:d3q3jv$1q48$2@digitaldaemon.com...
> >> >>
> >> >> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
> >> >> news:d3pt4s$1lbb$1@digitaldaemon.com...
> >> >> > My analogy with systems on an airplane is that the code that
> >> >> > realized a
> >> >> > subsystem failed and decided to shut that particular
> >> >> > subsystem
> >> >> > down
> >> >> > effectively "caught" the problem in the subsystem. The same
> >> >> > approach
> >> >> applies
> >> >> > to a piece of software that catches a problem in a subsystem
> >> >> > and deals
> >> >> with
> >> >> > it. Just as an error in a subsystem on an airplane doesn't
> >> >> > shut
> >> >> > down the
> >> >> > entire airplane so an error in a subsystem in a piece of
> >> >> > software should
> >> >> > shut down the entire software. I agree the level of safety
> >> >> > and
> >> >> > reduncancy
> >> >> is
> >> >> > much higher in an airplane but my argument was that
> >> >> > *something*
> >> >> > on that
> >> >> > airplane realized the subsystem was in error and dealt with
> >> >> > it.
> >> >>
> >> >> Ok. We're on the same page, then.
> >>
> >> I don't think they are on the same page, because that would
> >> assume
> >> that the barriers between valid and invalid code within a process
> >> are analogous to those between separate redundant computer
> >> systems
> >> with external arbitration mechanisms in an aircraft control
> >> system.
> >> Since the former have the extreme intimacy of a shared address
> >> space
> >> and thread(s) of execution, and the latter are (as far as I can
> >> guess, as I do not know) connected only by physical actuators and
> >> a
> >> shared power supply (maybe?), this analogy cannot hold.
> >>
> >> Yes, it's conceivable that one of the redundant computer systems
> >> on
> >> the aircraft could, in principle, cause, in its death throes,
> >> sufficient perturbation of the power supply of one of the other
> >> ones
> >> as to effect a catatrophic failure, but that is, I suggest,
> >> within
> >> the limit of acceptable risk. ;)
> >>
> >> Anyway, I've foresworn further comment on the issue until my
> >> article's published, so I'll shut up again. Sorry. ;-)
> >>
> >>
> >>
> >
> >
>
>
April 20, 2005
Re: Robust, fault-tolerant software is easier to write with D than C++. Or is it? [was: Re: recoverable and unrecoverable errors or exceptions]
"TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message 
news:d459k7$2q6s$1@digitaldaemon.com...
> It's not meant as an argument at all, but rather as a statement of 
> opinion from my perspective.

Opinion is worthless without argument.

> My point is exactly that...
> there are different perspectives.
> Yours is one.

Naturally.

> As for your statement that I was incorrectly addressing your point 
> by speaking of airplains and programs,
> you may want to consider the fact that I was attempting to address 
> the bigger picture, since the smaller sub-picture is obviously a 
> part of it.

So what? You appear to assume a given truth that such 
'magnification' is meaningful. Why? On what grounds? Is that some 
universal truth?

Focusing in is appropriate and meaningful in some cases; focusing 
out is in others; and zooming in any direction irrelevant to others. 
(Surely that's obvious almost to the point of axiom.)

> I didn't think it necessary to mention that within each airplane 
> are it's parts,
> and each part occupies a subset of the space that the airplane 
> occupies,
> or the fact that those parts are made of materials and/or 
> sub-parts which are in turn made of materials and/or sub-parts or 
> how such parts and sub-parts interact.
> The fact remains that it is a reasonable analogy whether or not 
> any specific person understands the connection or sees the 
> parallel.

It is absolutely _not_ a reasonable analogy. The constituent parts 
of a process may not be distinguised as separate in terms of safety, 
since they have an intimate relationship in terms of shared access 
to process resources, principally, but not exclusively, memory. To 
put forward the notion that separate aircraft, with independent 
control systems and, most importantly, sentient human beings, are as 
intimately linked is simply wrong.

For example, it is not the case that one aircraft flying some 100s 
or 1000s or even 10s of km away from another will suddenly find 
itself touching the same airspace of another, and therefore 
suffering from jetwash. But such proximity is not only possible and 
likely between intra-process entities, it is their very function. To 
deny this, or rather to aver that its converse is true, is either 
uninformed, mistaken or mendacious.

> You're obviously an intellegent person, but...

Assumption. But a nice one. Are you trying to disarm me with 
flattery? :-)

Far more important than intelligence - which not guarantee against 
ignorance, inexperience, vanity or criticism - I have a large and 
most certainly healthy portion of skepticism about my own wisdom 
_and_ that of others, which is why I always back up my opinions with 
reasoned argument, and why I am unable to give credit to those who 
do not. And I'm not afraid to say so. _And_, I don't see why one 
should be. Ignorance is not something to fear.

> you don't know "everything"

Naturally

>so your argument that my argument is plasmaware can't have taken 
>into account my knowledge or experiences that you lack awareness 
>of.

That's irrelevant. I do not know what you do or do not know. To 
imply that that's the foundation of my argument is specious.

I was commenting on an _argument_ which you advanced. If you wish to 
argue with that then do so, but please don't dress up my post and 
ascribe knowledge and intent of which you have no knowledge. That's, 
er, hypocrisy, no?

As to the arguments, which I did indeed comment on: When you make 
statements that are plainly - at least to me - nonsensical, I can't 
help but notice. Perhaps the wise, or at least the purposeful, 
course is to just ignore such things.

But then what's the point of this newsgroup? It's already 90% 
vacuous congratulation. For my part, I believe advancement is made 
through honest criticism, as readily of oneself as of others, and 
action to answer it, but it just doesn't seem to be something that 
people are able/willing/interested in doing in general.

Don't worry. I'm just about out of reserves of energy for swimming 
against the D stream. Which I think is a shame, but I suspect most 
others won't.

Meet me where the G.O.M. hang out. :-)

Matthew

P.S. Since it's become necessary for me to do so in respect of 
disagreement: None of the foregoing is meant as personal insult or 
slight to you, or as an attempt to make _you_ feel unwelcome to the 
newsgroup. Your enthusiasm and experience are welcome. (It may be 
mine that aren't <g>)

>
> TZ
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message 
> news:d450cf$2il5$1@digitaldaemon.com...
>> I applaud your dedication to painting a picture of unalloyed
>> fraternity, but your argument is plasmaware.
>>
>>     "It is, however, possible to designate a "portion" of the sky
>> for a specific aricraft, and a "portion" of the computer's 
>> addrerss
>> space for a specific program"
>>
>> You're not even correctly addressing my point, since the 
>> analogous
>> construct would be:
>>
>>     "a "portion" of the computer's address space for a
>> _subcomponent_ of a specific program"
>>
>> That is _at best_, as any programmer will tell you, 'not 
>> currently
>> realistic'.
>>
>> Anyway, I'm not getting into it any further, as being insulting
>> isn't good for anyone, and constantly going round the same old
>> houses of misapprehension is tiring, to say the least.
>>
>>
>> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message
>> news:d44uj9$2fqg$1@digitaldaemon.com...
>> > Well, that is one way of looking at it.  What I see though, is
>> > that they agree on the princible of what "should" be done, to 
>> > the
>> > extent that it is possible to do.  I also agree with the way 
>> > Ben
>> > put it, because there is a definate parallel there.
>> >
>> > For example, just like parts of a running program share the 
>> > same
>> > address space, the parts of  an aircraft in flight also share 
>> > the
>> > same sky.  For that matter, different programs on the same
>> > computer also share the same address space at least on a 
>> > hardware
>> > level, and likewise any number of distinct pieces of flying
>> > hardware may be carrying passangers and such around in the same
>> > sky at the same time.
>> >
>> > It is, however, possible to designate a "portion" of the sky 
>> > for a
>> > specific aricraft, and a "portion" of the computer's addrerss
>> > space for a specific program.  In both cases, there exists the
>> > possibility of the assigned boundaries being violated, and in
>> > either case, the results can potentially lead to a crash.
>> >
>> > With this in mind, remember that while the programmer has 
>> > little
>> > or no control over the nature of the hardware that the program
>> > will run on, the aircraft designer also has little or no 
>> > control
>> > over the atmosphere in which thier creation will fly.  As such,
>> > both the software engineer and the aricraft engineer are
>> > restricted in their ability to add fault tollerance, but there 
>> > are
>> > still things that can be done even within such restrictions.
>> >
>> > Microprocessors make mistakes all the time... and I don't mean
>> > simply that they make mistakes every so many billion 
>> > operations.
>> > The whole reason it's so hard for microprocessor designers to 
>> > keep
>> > finding ways to make them smaller, is because their very design 
>> > is
>> > based on the idea that electrons will go where they want 
>> > whether
>> > we like it or not.
>> >
>> > Make it a little easier for electrons to go one way than 
>> > another
>> > way, and more of them will take the easier way.  Meanwhile, a 
>> > few
>> > will take the harder way because those they were repelled by 
>> > those
>> > taking the easier way, and a few will take the harder way 
>> > because
>> > their particular allignment made that way easier for them
>> > specifically, and a few will take the harder way simply because
>> > "they can" but the chip is designed to take advantage of the
>> > "average" action by using excessive redundancy.  As chips get
>> > smaller, the amount of redundancy possible in a single electron
>> > path decreases substantially, and compensations have to be 
>> > made.
>> >
>> > In other words, if every stray electron that went "the wrong 
>> > way"
>> > crashed the microprocessor that it was traveling through, there
>> > wouldn't be time to execute a single hardwired microcode
>> > instruction like "fetch" before the chip crashed.
>> >
>> > Extreme fault tollerance requires sacrafice though.  You could 
>> > use
>> > hashes and checksums all over the place, and redundantly write
>> > every piece of data to multiple memory locations, and 
>> > periodically
>> > back up every piece of data to external storage along with the
>> > processor state and so on... but don't expect your program to 
>> > get
>> > anything done while you're still alive to see it because it 
>> > would
>> > be so slow it would pass for frozen.
>> >
>> > Looks to me like Walter and Ben have the right idea.  Yes, it 
>> > may
>> > be foriegn to you, but that doesn't mean it won't work.  Give 
>> > it a
>> > chance... see how it works out.
>> >
>> > TZ
>> >
>> > "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
>> > news:d44q3s$2cmj$1@digitaldaemon.com...
>> >>
>> >> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message
>> >> news:d44p6j$2c2a$1@digitaldaemon.com...
>> >> > Looks like a good page to be on too.  :)
>> >> >
>> >> > TZ
>> >> >
>> >> > "Walter" <newshound@digitalmars.com> wrote in message
>> >> > news:d3q3jv$1q48$2@digitaldaemon.com...
>> >> >>
>> >> >> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
>> >> >> news:d3pt4s$1lbb$1@digitaldaemon.com...
>> >> >> > My analogy with systems on an airplane is that the code 
>> >> >> > that
>> >> >> > realized a
>> >> >> > subsystem failed and decided to shut that particular
>> >> >> > subsystem
>> >> >> > down
>> >> >> > effectively "caught" the problem in the subsystem. The 
>> >> >> > same
>> >> >> > approach
>> >> >> applies
>> >> >> > to a piece of software that catches a problem in a 
>> >> >> > subsystem
>> >> >> > and deals
>> >> >> with
>> >> >> > it. Just as an error in a subsystem on an airplane 
>> >> >> > doesn't
>> >> >> > shut
>> >> >> > down the
>> >> >> > entire airplane so an error in a subsystem in a piece of
>> >> >> > software should
>> >> >> > shut down the entire software. I agree the level of 
>> >> >> > safety
>> >> >> > and
>> >> >> > reduncancy
>> >> >> is
>> >> >> > much higher in an airplane but my argument was that
>> >> >> > *something*
>> >> >> > on that
>> >> >> > airplane realized the subsystem was in error and dealt 
>> >> >> > with
>> >> >> > it.
>> >> >>
>> >> >> Ok. We're on the same page, then.
>> >>
>> >> I don't think they are on the same page, because that would
>> >> assume
>> >> that the barriers between valid and invalid code within a 
>> >> process
>> >> are analogous to those between separate redundant computer
>> >> systems
>> >> with external arbitration mechanisms in an aircraft control
>> >> system.
>> >> Since the former have the extreme intimacy of a shared address
>> >> space
>> >> and thread(s) of execution, and the latter are (as far as I 
>> >> can
>> >> guess, as I do not know) connected only by physical actuators 
>> >> and
>> >> a
>> >> shared power supply (maybe?), this analogy cannot hold.
>> >>
>> >> Yes, it's conceivable that one of the redundant computer 
>> >> systems
>> >> on
>> >> the aircraft could, in principle, cause, in its death throes,
>> >> sufficient perturbation of the power supply of one of the 
>> >> other
>> >> ones
>> >> as to effect a catatrophic failure, but that is, I suggest,
>> >> within
>> >> the limit of acceptable risk. ;)
>> >>
>> >> Anyway, I've foresworn further comment on the issue until my
>> >> article's published, so I'll shut up again. Sorry. ;-)
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>
April 20, 2005
Re: recoverable and unrecoverable errors or exceptions
Walter wrote:
>> Is it possible at all to have the Old Farts, who hold the keys to
>> Programming World, to become susceptible to our demands?
> 
> LOL.

Suppose the "over 60" bit type was actually 63 bits.

How many would seriously start crying about 63 bits being seriously 
deficient? Their opposition would surely suggest 127 bits for those 
purposes.

Well now we would have 2^64 - 1 values. We lose one single value. A 
national Disaster.

And we'd lose this value _only_ in situations where we're dealing with a 
possibly uninitialized value.

Not a huge loss, IMHO.

The specific issue here is that "they" are so old, that they'd have a 
hard time noticing all of a sudden that we actually do have values to 
spare. Extending this thought, it should be equally hard to have them 
designate one single value for NAN even with 1024 bit integers. (Seriously.)

I can see the worries of these guys. Traditionally a lot of code has 
been dependent on "integer" overflow hardware traps, wich have been 
extensively used when doing integer arithmetic wider than the 
accumulator in the processor.

And even today, with all kinds of encryption getting increasingly 
important, that is not going to go away.

I think this would not be hampered in any way with a compiler that 
initialises ints with this NAN value (in the cases where it can't 
immediately see for sure that the variable is assigned a value before 
first use).

By the same token, at reading the value in all places where the compiler 
"knows" that the variable is already initialised, the NAN checks would 
not be done.

-----

While I'm not suggesting or demanding, I still write the following:

(Oh, and don't anybody even think of D 1.0 here. This is purely academic 
at this stage.)

There are several alternative things one could do here:

1) Suppose we create a new data type, called GuardedInt64. This type 
would always be checked against the NAN value upon retrieval. (A single 
machine instruction comparing with an immediate value. Not Enormously Slow.)

2) Or, we could decide that non-release builds check against NAN if 
there is reason to be unsure whether the variable is already 
initialised. If the compiler can see that there is no danger of that, 
then it would not bother to check. (This NAN thing would also be 
switchable on the command line, and/or with a pragma.)

3) Or, in non-release code, for every int there could be a "shadow 
variable", whose purpose would only be to know whether the real variable 
was already initialised. (This would be slow, but hey, non-release code 
in D is already slower -- which is OK.) (The naïve implementation being 
that every time you write to your int, the shadow int gets written a 1. 
And every time you read yuor int, the shadow int gets checked for null. 
Null denoting that we have a read before any write.)

4-300) And probably hundreds of other variations. :-)

-----------

It's a shame that we don't yet have the Micro Forks releases (those 
"Everyone Tinker Yourself Instead of Crowding the Newsgroup with Demands 
and Dreams" packages.)

It would be so easy for someone to create a (for example) GuardedInt64 
type, and let others use that particular compiler for a while, for some 
real-world experiences.

With the same effort, probably anybody doing that would implement the 
same for 32bit ints, both signed and unsigned. This would give us even 
more real world experience.

(( Aahh, the Micro Forks releases! Man, we could
   speed up D research and development! We'd
   multiply the speed, instead of merely adding.

   Why do you think open source runs circles
   around Bill, and even Larry E? It's not that
   there are thousands of developers. It's that
   everyone gets the code to tinker with, doing
   his on pet peeve, or his own dream. A lot
   of tiny springs make the Amazon.

   We need them now, not when D is at 5.5.

   Ha, the C++ Beards wouldn't even know what hit
   them, by that time we'd be in Jupiter!
))

Actually, this could be done with my (still in planning ;-( ) "D 
preprocessor / D language lab / D meta language compiler". But, alas, 
that's at least months away (if not Quarters). I wish I were 30 years 
younger!

But more practical, sooner, and for the common good a lot better 
solution would really be the Micro Forks tinkering distro. (Be it 
Walter's, Anders', David's or somebody else's.)

-----------

A language that has the audacity to screw up thoroughly established 
practices ("bit" booleans, a serious language with GC, etc. (disclaimer: 
IMHO the latter is good)), could very well be the one forerunner with 
int-NANs.

_Somebody_ has to take the first step.
April 20, 2005
Re: Robust, fault-tolerant software is easier to write with D than C++. Or is it? [was: Re: recoverable and unrecoverable errors or exceptions]
Opinion without argument is no more meaningless than disagreement without war.
I've stated my opinion, and you obviously disagree with it.
I can accept that, without having to choose between asserting that I am "still right" or conceding that I must have been mistaken.
I am sure of what I stated containing valuable and accurate information.
You can either find the value and benefit from it, or insist that it doesn't exist because you can't see it.
That choice is yours.
I have no wish to argue.

TZ

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d45djj$2tv2$1@digitaldaemon.com...
>
> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message
> news:d459k7$2q6s$1@digitaldaemon.com...
> > It's not meant as an argument at all, but rather as a statement of
> > opinion from my perspective.
>
> Opinion is worthless without argument.
>
> > My point is exactly that...
> > there are different perspectives.
> > Yours is one.
>
> Naturally.
>
> > As for your statement that I was incorrectly addressing your point
> > by speaking of airplains and programs,
> > you may want to consider the fact that I was attempting to address
> > the bigger picture, since the smaller sub-picture is obviously a
> > part of it.
>
> So what? You appear to assume a given truth that such
> 'magnification' is meaningful. Why? On what grounds? Is that some
> universal truth?
>
> Focusing in is appropriate and meaningful in some cases; focusing
> out is in others; and zooming in any direction irrelevant to others.
> (Surely that's obvious almost to the point of axiom.)
>
> > I didn't think it necessary to mention that within each airplane
> > are it's parts,
> > and each part occupies a subset of the space that the airplane
> > occupies,
> > or the fact that those parts are made of materials and/or
> > sub-parts which are in turn made of materials and/or sub-parts or
> > how such parts and sub-parts interact.
> > The fact remains that it is a reasonable analogy whether or not
> > any specific person understands the connection or sees the
> > parallel.
>
> It is absolutely _not_ a reasonable analogy. The constituent parts
> of a process may not be distinguised as separate in terms of safety,
> since they have an intimate relationship in terms of shared access
> to process resources, principally, but not exclusively, memory. To
> put forward the notion that separate aircraft, with independent
> control systems and, most importantly, sentient human beings, are as
> intimately linked is simply wrong.
>
> For example, it is not the case that one aircraft flying some 100s
> or 1000s or even 10s of km away from another will suddenly find
> itself touching the same airspace of another, and therefore
> suffering from jetwash. But such proximity is not only possible and
> likely between intra-process entities, it is their very function. To
> deny this, or rather to aver that its converse is true, is either
> uninformed, mistaken or mendacious.
>
> > You're obviously an intellegent person, but...
>
> Assumption. But a nice one. Are you trying to disarm me with
> flattery? :-)
>
> Far more important than intelligence - which not guarantee against
> ignorance, inexperience, vanity or criticism - I have a large and
> most certainly healthy portion of skepticism about my own wisdom
> _and_ that of others, which is why I always back up my opinions with
> reasoned argument, and why I am unable to give credit to those who
> do not. And I'm not afraid to say so. _And_, I don't see why one
> should be. Ignorance is not something to fear.
>
> > you don't know "everything"
>
> Naturally
>
> >so your argument that my argument is plasmaware can't have taken
> >into account my knowledge or experiences that you lack awareness
> >of.
>
> That's irrelevant. I do not know what you do or do not know. To
> imply that that's the foundation of my argument is specious.
>
> I was commenting on an _argument_ which you advanced. If you wish to
> argue with that then do so, but please don't dress up my post and
> ascribe knowledge and intent of which you have no knowledge. That's,
> er, hypocrisy, no?
>
> As to the arguments, which I did indeed comment on: When you make
> statements that are plainly - at least to me - nonsensical, I can't
> help but notice. Perhaps the wise, or at least the purposeful,
> course is to just ignore such things.
>
> But then what's the point of this newsgroup? It's already 90%
> vacuous congratulation. For my part, I believe advancement is made
> through honest criticism, as readily of oneself as of others, and
> action to answer it, but it just doesn't seem to be something that
> people are able/willing/interested in doing in general.
>
> Don't worry. I'm just about out of reserves of energy for swimming
> against the D stream. Which I think is a shame, but I suspect most
> others won't.
>
> Meet me where the G.O.M. hang out. :-)
>
> Matthew
>
> P.S. Since it's become necessary for me to do so in respect of
> disagreement: None of the foregoing is meant as personal insult or
> slight to you, or as an attempt to make _you_ feel unwelcome to the
> newsgroup. Your enthusiasm and experience are welcome. (It may be
> mine that aren't <g>)
>
> >
> > TZ
> >
> > "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
> > news:d450cf$2il5$1@digitaldaemon.com...
> >> I applaud your dedication to painting a picture of unalloyed
> >> fraternity, but your argument is plasmaware.
> >>
> >>     "It is, however, possible to designate a "portion" of the sky
> >> for a specific aricraft, and a "portion" of the computer's
> >> addrerss
> >> space for a specific program"
> >>
> >> You're not even correctly addressing my point, since the
> >> analogous
> >> construct would be:
> >>
> >>     "a "portion" of the computer's address space for a
> >> _subcomponent_ of a specific program"
> >>
> >> That is _at best_, as any programmer will tell you, 'not
> >> currently
> >> realistic'.
> >>
> >> Anyway, I'm not getting into it any further, as being insulting
> >> isn't good for anyone, and constantly going round the same old
> >> houses of misapprehension is tiring, to say the least.
> >>
> >>
> >> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message
> >> news:d44uj9$2fqg$1@digitaldaemon.com...
> >> > Well, that is one way of looking at it.  What I see though, is
> >> > that they agree on the princible of what "should" be done, to
> >> > the
> >> > extent that it is possible to do.  I also agree with the way
> >> > Ben
> >> > put it, because there is a definate parallel there.
> >> >
> >> > For example, just like parts of a running program share the
> >> > same
> >> > address space, the parts of  an aircraft in flight also share
> >> > the
> >> > same sky.  For that matter, different programs on the same
> >> > computer also share the same address space at least on a
> >> > hardware
> >> > level, and likewise any number of distinct pieces of flying
> >> > hardware may be carrying passangers and such around in the same
> >> > sky at the same time.
> >> >
> >> > It is, however, possible to designate a "portion" of the sky
> >> > for a
> >> > specific aricraft, and a "portion" of the computer's addrerss
> >> > space for a specific program.  In both cases, there exists the
> >> > possibility of the assigned boundaries being violated, and in
> >> > either case, the results can potentially lead to a crash.
> >> >
> >> > With this in mind, remember that while the programmer has
> >> > little
> >> > or no control over the nature of the hardware that the program
> >> > will run on, the aircraft designer also has little or no
> >> > control
> >> > over the atmosphere in which thier creation will fly.  As such,
> >> > both the software engineer and the aricraft engineer are
> >> > restricted in their ability to add fault tollerance, but there
> >> > are
> >> > still things that can be done even within such restrictions.
> >> >
> >> > Microprocessors make mistakes all the time... and I don't mean
> >> > simply that they make mistakes every so many billion
> >> > operations.
> >> > The whole reason it's so hard for microprocessor designers to
> >> > keep
> >> > finding ways to make them smaller, is because their very design
> >> > is
> >> > based on the idea that electrons will go where they want
> >> > whether
> >> > we like it or not.
> >> >
> >> > Make it a little easier for electrons to go one way than
> >> > another
> >> > way, and more of them will take the easier way.  Meanwhile, a
> >> > few
> >> > will take the harder way because those they were repelled by
> >> > those
> >> > taking the easier way, and a few will take the harder way
> >> > because
> >> > their particular allignment made that way easier for them
> >> > specifically, and a few will take the harder way simply because
> >> > "they can" but the chip is designed to take advantage of the
> >> > "average" action by using excessive redundancy.  As chips get
> >> > smaller, the amount of redundancy possible in a single electron
> >> > path decreases substantially, and compensations have to be
> >> > made.
> >> >
> >> > In other words, if every stray electron that went "the wrong
> >> > way"
> >> > crashed the microprocessor that it was traveling through, there
> >> > wouldn't be time to execute a single hardwired microcode
> >> > instruction like "fetch" before the chip crashed.
> >> >
> >> > Extreme fault tollerance requires sacrafice though.  You could
> >> > use
> >> > hashes and checksums all over the place, and redundantly write
> >> > every piece of data to multiple memory locations, and
> >> > periodically
> >> > back up every piece of data to external storage along with the
> >> > processor state and so on... but don't expect your program to
> >> > get
> >> > anything done while you're still alive to see it because it
> >> > would
> >> > be so slow it would pass for frozen.
> >> >
> >> > Looks to me like Walter and Ben have the right idea.  Yes, it
> >> > may
> >> > be foriegn to you, but that doesn't mean it won't work.  Give
> >> > it a
> >> > chance... see how it works out.
> >> >
> >> > TZ
> >> >
> >> > "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
> >> > news:d44q3s$2cmj$1@digitaldaemon.com...
> >> >>
> >> >> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message
> >> >> news:d44p6j$2c2a$1@digitaldaemon.com...
> >> >> > Looks like a good page to be on too.  :)
> >> >> >
> >> >> > TZ
> >> >> >
> >> >> > "Walter" <newshound@digitalmars.com> wrote in message
> >> >> > news:d3q3jv$1q48$2@digitaldaemon.com...
> >> >> >>
> >> >> >> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
> >> >> >> news:d3pt4s$1lbb$1@digitaldaemon.com...
> >> >> >> > My analogy with systems on an airplane is that the code
> >> >> >> > that
> >> >> >> > realized a
> >> >> >> > subsystem failed and decided to shut that particular
> >> >> >> > subsystem
> >> >> >> > down
> >> >> >> > effectively "caught" the problem in the subsystem. The
> >> >> >> > same
> >> >> >> > approach
> >> >> >> applies
> >> >> >> > to a piece of software that catches a problem in a
> >> >> >> > subsystem
> >> >> >> > and deals
> >> >> >> with
> >> >> >> > it. Just as an error in a subsystem on an airplane
> >> >> >> > doesn't
> >> >> >> > shut
> >> >> >> > down the
> >> >> >> > entire airplane so an error in a subsystem in a piece of
> >> >> >> > software should
> >> >> >> > shut down the entire software. I agree the level of
> >> >> >> > safety
> >> >> >> > and
> >> >> >> > reduncancy
> >> >> >> is
> >> >> >> > much higher in an airplane but my argument was that
> >> >> >> > *something*
> >> >> >> > on that
> >> >> >> > airplane realized the subsystem was in error and dealt
> >> >> >> > with
> >> >> >> > it.
> >> >> >>
> >> >> >> Ok. We're on the same page, then.
> >> >>
> >> >> I don't think they are on the same page, because that would
> >> >> assume
> >> >> that the barriers between valid and invalid code within a
> >> >> process
> >> >> are analogous to those between separate redundant computer
> >> >> systems
> >> >> with external arbitration mechanisms in an aircraft control
> >> >> system.
> >> >> Since the former have the extreme intimacy of a shared address
> >> >> space
> >> >> and thread(s) of execution, and the latter are (as far as I
> >> >> can
> >> >> guess, as I do not know) connected only by physical actuators
> >> >> and
> >> >> a
> >> >> shared power supply (maybe?), this analogy cannot hold.
> >> >>
> >> >> Yes, it's conceivable that one of the redundant computer
> >> >> systems
> >> >> on
> >> >> the aircraft could, in principle, cause, in its death throes,
> >> >> sufficient perturbation of the power supply of one of the
> >> >> other
> >> >> ones
> >> >> as to effect a catatrophic failure, but that is, I suggest,
> >> >> within
> >> >> the limit of acceptable risk. ;)
> >> >>
> >> >> Anyway, I've foresworn further comment on the issue until my
> >> >> article's published, so I'll shut up again. Sorry. ;-)
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>
10 11 12 13 14 15
Top | Discussion index | About this forum | D home