File browser

[Daniele Futtorovic]

Thank you, very much, for that information and link. I note that she
writes "Adding this as a requirement was not universally popular,
since it does not affect all programs". In other words, there are
actually predictably safe scenarios...that is, some _programs_ are
not affected and thus it's a matter of the code, not the exact timing
of the execution of the code (as is the situation when there's an
actual synchronization bug). At least that's how I read that.

I would love to learn more about the issue, to find out what specific
scenarios are safe and which ones are not. But I am getting the
impression that it's not a popular topic to discuss and that at least
some people don't share my feeling that it's useful to know how
things break, even if you already know a good rule for avoiding
breaking things.

For those who agree that it's useful to know how things break, and/or
who have more specific information on how things might break
initializing GUI components off the EDT thread and are interested in
sharing that information, I welcome any additional input.

I've looked a bit for the tutorials Sharon Zakhour spoke about in the
blog mentioned above. She wrote she didn't remember exactly which demo
it was which was broken: "it might have been the DocumentEvent demo or
one of the Text component demos" .
The older version of DocumentEventDemo used a JApplet, so I suppose that
wasn't the one. There is one "TextComponentDemo", however. Here's a
version from 2002 which initialises and starts the GUI from the main thread:

Part 1:
<http://web.archive.org/web/20021220132313/http://java.sun.com/docs/books/tutorial/
uiswing/components/example-swing/TextComponentDemo.java>

Part 2:
<http://web.archive.org/web/20021220132058/http://java.sun.com/docs/books/tutorial/
uiswing/components/example-swing/LimitedStyledDocument.java>

You could try with these. Another way would be to ask Sharon Zakhour
herself.


As a sidenote, due to some of your comments in this thread, I was
wondering whether you properly realised that the whole Swing framework
used one and the same event dispatch mechanism, the same as the "user",
and how complex a framework it is altogether. I can't tell you how some
code might break if you initialise it from the main thread (though the
code linked to above might provide an answer, but I don't have the time,
and quite frankly little motivation, to investigate it now), but neither
could I tell of any non-trivial code that it would be guaranteed to
work. There's simply quite a lot going on behind the scenes. And I hope
you realise that Lew's and, to a lesser extent, Daniel's rigidity on
this matter is partly owed to the very fact that it's difficult to know
how these things could break.

DF.

 

[Filip Larsen]

Peter Duniho skrev:

For those who agree that it's useful to know how things break, and/or
who have more specific information on how things might break
initializing GUI components off the EDT thread and are interested in
sharing that information, I welcome any additional input.

I don't know if it'll help, but a few years back (on 1.4) I had an
application that started to appear completely blank after startup until
the main window was resized, after which it appeared to work normally
(no deadlock). The application did a lot of GUI initialization in the
sense that it would construct the component tree with minimal
initialization of each component and then, before making the root
visible, recursively run through all the components setting attributes
(including layout manager setup) according to a configuration.

Unfortunately I only analyzed the problem until I found out that moving
the initialization to the EDT made the problem go away, so I can only
speculate that initialization on the main thread made some of the
components miss some important events that they didn't miss if
initialized on the EDT. Anyway, since then I've stuck to the advice of
always initializing on the EDT.

However, I have never experienced an application deadlocking during GUI
initialization, so the above effect could easily be something different
than whatever the advice to do initialization on the EDT is meant to
guard against.


Regards,

 

[Bent C Dalager]

[...]
I know what *might* go wrong - you might have an improper value
displayed in a control, for example. You might have a control not be
visible at all - it depends on the work that's being done.

How could those things happen?

They will tend to happen due to race conditions or due to data
synchronization issues. If you are looking for a comprehensive
treatment of such problems, you will need to consult a concurrency
text book. It is rather a large issue, ill fit for comprehensive
discussion in this thread.

What Sun is saying is basically this: "If you don't do <X>, then Swing
will give you threading issues." They don't go much into the details
and, indeed, this is not necessary since threading issues are always
undesirable regardless of the specifics of each individual problem
case.

To understand what it actually means and why you would want to avoid
it, read up on threading in general.

Cheers,
Bent D

 

[Peter Duniho]

[...]
The older version of DocumentEventDemo used a JApplet, so I suppose that
wasn't the one. There is one "TextComponentDemo", however. Here's a
version from 2002 which initialises and starts the GUI from the main
thread:

Part 1:
<http://web.archive.org/web/20021220132313/http://java.sun.com/docs/books/tutorial/
uiswing/components/example-swing/TextComponentDemo.java>

Part 2:
<http://web.archive.org/web/20021220132058/http://java.sun.com/docs/books/tutorial/
uiswing/components/example-swing/LimitedStyledDocument.java>

You could try with these. Another way would be to ask Sharon Zakhour
herself.

Thanks, all good suggestions. I will follow up with more information if I
learn anything via those routes.

As a sidenote, due to some of your comments in this thread, I was
wondering whether you properly realised that the whole Swing framework
used one and the same event dispatch mechanism, the same as the "user",
and how complex a framework it is altogether.

I can't say I've ever seen a framework that I wouldn't characterize as
"complex". So I'm also not sure if you're trying to suggest that the
Swing framework is more complex than most, or if it's simply that it's as
complex as any similar one would be.

As far as the event dispatching goes, yes...I was aware, even before I
knew what "EDT" was an abbreviation of, that all of the event handling was
done on a single thread. This isn't really all that atypical anyway.
Even in the native Windows API, where it's theoretically possibly to have
multiple threads with their own message pumps, that's a very unusual
situation. I'm quite used to the idea of having a single thread manage
the entire GUI.

I can't tell you how some
code might break if you initialise it from the main thread (though the
code linked to above might provide an answer, but I don't have the time,
and quite frankly little motivation, to investigate it now), but neither
could I tell of any non-trivial code that it would be guaranteed to
work.

Well, that's the thing. I guess it's the definition of "non-trivial"
that's at question, but it's not like the code I'm writing right now is
all that complicated. The GUI amounts to a couple of instances of a
single custom control class, and then a handful of buttons. They are
created, and then added to the main frame for the application. That's it.

There's simply quite a lot going on behind the scenes. And I hope
you realise that Lew's and, to a lesser extent, Daniel's rigidity on
this matter is partly owed to the very fact that it's difficult to know
how these things could break.

I haven't found Daniel's replies to be rigid. In fact, I've found his
comments to be reasonably helpful. He hasn't answered the specific
question at hand, but neither has he implied that he knows the answer. I
don't expect people to do my homework for me, but I don't see what the
harm would be, if someone _already knows_ the answer, in them sharing it.

Reiterating again: the advice to always initialize the GUI on the EDT is
not something I disagree with, or otherwise have any reason to question.
If someone is rigid on that point only, I don't have an issue with that.
It's the rigid refusal to share information that one knows that I object
to.

As far as it being "difficult to know how these things could break", I
suppose that depends on what you mean. I agree that in using a framework
or other API that has a complex implementation, it's difficult to predict
_all_ of the things that might go wrong should you fail to comply with the
framework's rules. But that's very different from the question of whether
one can predict _something_ that might go wrong.

As a very simple example of what I mean, consider a single unsynchronized
variable used by multiple threads. There are a number of things that
_might_ go wrong do that. It would be difficult to enumerate all of the
possible ways it might fail. But it's very simple to construct an example
of some ways, or even just one, that doing that will consistently fail.

In this case, I'm not looking for a complete discussion of all of the
different ways this might fail. But it would be helpful for my
understanding to see at least one example of something that consistently
will fail.

I am hopeful that the sample you've found is indeed the one that was
referenced and that I can consistently get it to deadlock. From the blog
post, it's not at all clear that the sample will be applicable to
something as simple as my own code, but it would still be informative.
Thank you very much for providing the link.

Pete

 

[Peter Duniho]

[...]
Unfortunately I only analyzed the problem until I found out that moving
the initialization to the EDT made the problem go away, so I can only
speculate that initialization on the main thread made some of the
components miss some important events that they didn't miss if
initialized on the EDT. Anyway, since then I've stuck to the advice of
always initializing on the EDT.

However, I have never experienced an application deadlocking during GUI
initialization, so the above effect could easily be something different
than whatever the advice to do initialization on the EDT is meant to
guard against.

Actually, your experience is helpful, or at least potentially so.

Awhile back (in a different thread, I think), I mentioned that I had a
small sample application that sometimes would not show a button when the
application started. Very similar symptoms to those you describe.

At the time, someone else suggested it might be because I was mixing Swing
and AWT components. And in fact, I was able to make the problem stop by
not mixing Swing and AWT components.

But I suppose it's possible that the issue was really where I was doing
the initialization, and that making the whole thing AWT-only simply
changed the timing a bit to obscure the problem (a common difficulty in
debugging synchronization bugs).

I'm not entirely sure how that would lead to a demonstration sample that
I'm looking for, but it's a start. The sample I had was very simple: just
three components, and it's possible I could reduce that to two, or maybe
even just one. That should make it at least a little simpler to see what
exactly is going on during the initialization of the GUI and whether I can
force the problem to occur 100% of the time by careful control of the
order of operations.

Thanks for sharing.

Pete

 

[Peter Duniho]

[...]
To understand what it actually means and why you would want to avoid
it, read up on threading in general.

I already know quite a bit about threading. Concurrency issues in general
are not outside my experience.

The question here is: what is it that is happening on the EDT during the
initialization of the GUI, given that the GUI hasn't actually be presented
yet? And how does that, presumably prompted by some specific
initialization code, interact with the rest of the initialization code
that follows?

To wit: if there's a problem it must be because the components still wind
up receiving events on the EDT, in spite of the components not being
"realized" yet. My question is more about how this happens, and whether
it's an unavoidable part of simply creating a component, or if it's
something that happens only if a component is initialized or accessed in a
particular way?

I understand that this may be somewhat esoteric, but I don't think it's an
unreasonable question to ask. If no one has an answer, that's fine. But
I don't think it's useful or even reasonable to tell me I shouldn't be
asking the question.

Pete

 

[Bent C Dalager]

The question here is: what is it that is happening on the EDT during the
initialization of the GUI, given that the GUI hasn't actually be presented
yet?

I expect one common mistake may be to call pack() on a window and not
realize that this, well, realizes it.

I am sure there are other pitfalls as well, many of them hidden away
deep within the implementations of various Swing components.

Cheers,
Bent D

 

[Nigel Wade]

[...]

I can easily write code that will consistently produce wrong results
with
incorrect synchronization. It's true that one can get lucky and have it
work without. But it's also true that it's relatively simple to force a
problem in order to demonstrate the risk of failing to synchronize.

Yes, but to do that you need to be in control of the competing threads.
With the EDT you are not.

Sure, you are. Any time you get your code to be called on the EDT, you
are now in control. Until your code returns, you remain in control.

If your initialization code is run on the main thread (or any thread other than
the EDT) you are not in control of the EDT. That's the entire point. Behind the
scenes, in code you don't have access to, Swing may start the EDT. When or what
starts the EDT isn't documented anywhere I have ever seen. To control the EDT
you *have* to initialize your GUI on the EDT.

The outdated guidance that you could initialize the GUI on the main thread, up
until the point that the first component was realized, I believe was based on
the assumption that that was when the EDT was started. At least that's how I
remember it being presented. However, that assumption was either incorrect, or
has been rendered incorrect by later changes to the internal workings of Swing.

All I need to know to write working code is that the GUI must be initialized on
the EDT. I don't really need to know why. I don't need to know exectly when the
EDT starts, only that it will start at some point and run my code correctly.
The innner workings are irrelevent to my code, just as I don't need to know the
inner working of TCP/IP stack in order to make an HTTP request of a web server.

So it should be simple enough to write code that intentionally causes
something to be called on the EDT, at which point one can take advantage
of that control to ensure a synchronization error.

It would be nice if you could provide a practical demonstration of that theory.
However, I doubt it's possible in reality because the timing issues which are
necessary to cause the synchronization error are probably not under your
control.

One of the previously-cited articles does in fact do something like this.
Unfortunately, because it's specifically using invokeLater() to get code
to execute on the EDT, it's not a demonstration of the problem I'm asking
about. It does reliably demonstrate the potential for a problem that
could occur when your own code intentially puts something for execution on
the EDT, but it doesn't help me better understand how someone could
unintentionally have something execute on the EDT prior to any components
being visible.

[...]
The EDT is event driven, events which are affected by user actions and
the
exact timing of those actions, plus other factors external to your
application
which are handled by the OS.

Before any components are shown, user actions won't affect when things are
executed on the EDT.

Yes, they will. The GUI is part of the windowing system. The windowing system is
part of the OS, or controlled by the OS. Events are passed from the
mouse/keyboard to the windowing system via the OS, and then on to your
application. The timing and order of those events, and the timing of exactly
when EDT is able to act on them, is dependent on what the OS and the user is
doing. The GUI of your application is not an isolated system.

So, what of those "factors external to your
application"? What factors exist during initialization, prior to any
components being shown, that might cause something to happen on the EDT?

I have no idea. You'd need to dig around for yourself in the internal workings
of the Swing source code to to discover that.

However, we know they do exist, we've seen them happen.

I should reiterate that none of my questions are intended to suggest that
the advice given is wrong. They are only intended to solicit more
information that would help me understand better what the specific risks
are.

Remember: "I don't know" is an acceptable answer. I just don't appreciate
the attitude conveyed to me that _I_ don't need to know.

There's sufficient observational evidence to support the fact that you have to
initialize on the EDT if you want your code to be reliable. The theory behind
this, whilst intellectually intersting, isn't a pre-reququiste to writing
reliable code.

Good luck in your search for the knowlege you desire. If you really, really have
to know this then you probably need to either contact Sun directly and ask
them, or get the source code and work it out for yourself. For myself, I'm
happy to follow the guidance and initialize my GUI on the EDT.

 

[fchang]

Thank you, very much, for that information and link...
some _programs_ are not affected and thus it's a matter of the code,
not the exact timing of the execution of the code

Those are not mutually exclusive.

The root cause could still be a timing of different threads...
but some program are *indeed* not affected due to the way they are
written and how that *happens* to interact with the current
implementation of Java.

I would love to learn more about the issue, to find out what specific
scenarios are safe and which ones are not.

Two things you are surely aware of are:

1) GUI programs have many behind-the-scene interaction with the OS.
For example, on Linux, it would have to start an X connection,
query the color depth, retrieve the list of allowable XVisual value
on the machine, retrieve the number of screens and their screen
dimensions... These will update some internal fields in Swing.
Some of these fields might be read by your GUI construction code
(for example, the GUI construction code needs to bind your GUI
objects to native GUI objects on the OS)

2) There are many different implementations of Java.
We have Sun Java, IBM S9 Java, Mac's custom port of Java,
Linux GCJ... and we have many different native bindings even
on same OS. On Linux, for example, there are different builds
that bind to Gnome versus XIntrinsic versus...
The Swing's internal initialization code would differ greatly.

So... whatever knowledge you gain here, in my humble opinion,
is next to useless.

If someone initializes GUI on the EDT, and a bug occurs,
then it would be a legitimate bug that your Java vendor should fix,
since the official spec says so.

If someone initializes GUI on the main thread, and a bug occurs,
then it is that someone's own fault.

So... it's really a pragmatic issue: do you spend a week chasing
shadows and learn something useless, or just stick to the principle.

-

 

[Larry A Barowski]

For what it's worth, it's not just the look-and-feel stuff I've found to
be unreliable on the Mac. I have run into a number of inconsistencies and
difficulties using Java on the Mac. The most recent being its poor
handling of HTML presentation in components (it doesn't handle the
"&mdash;" character entitity, for example).

That is because support is only for HTML 3.2, which didn't have
&mdash; . It has nothing to do with the OS or font encoding; you
can't use it on Java for Windows either.

 

[Lew]

I don't know if it'll help, but a few years back (on 1.4) I had an
application that started to appear completely blank after startup until
the main window was resized, after which it appeared to work normally
(no deadlock). The application did a lot of GUI initialization in the
sense that it would construct the component tree with minimal
initialization of each component and then, before making the root
visible, recursively run through all the components setting attributes
(including layout manager setup) according to a configuration.

This is exactly what I suggested could happen in response to Peter's question.

I know what *might* go wrong - you might have an improper value displayed in a control,
for example. You might have a control not be visible at all - it depends on the work
that's being done.

It is good to hear of a real-life example.

 

[Lew]

[...]
I know what *might* go wrong - you might have an improper value
displayed in a control, for example. You might have a control not be
visible at all - it depends on the work that's being done.

How could those things happen? Specifically, that is, how could those
things happen should I initialize the controls off the EDT?

If you initialize some stuff off the EDT, the changes might not be visible to
the EDT when it renders the window, because the values you set might not
propagate through the memory model for the EDT to know to show them.

This is a standard synchronization issue, the same as in any multi-threaded
program.

I don't see how you get "snarky" from my replies. I'm simply asking
questions. If you don't know the answer, that's fine. Don't insist
that the questions or their answers are trivial though. That's just silly.

I never said they were trivial, I said the answers were given.

Misrepresenting my points and calling them "silly" is what I call "snarky".

No, you're not. If you were sorry, you would help by pointing out where

Oh, so now you're a mind reader?

in those articles those hints are contained and how to use them to
produce a working sample.

Here's the part that gave me the hint:

The reason behind the change is simple: while your program might access a
Swing component off of the event-dispatch thread before the component is realized,

OK, so I create components in the main thread, do a whole bunch of stuff to
them (add subcomponents, etc.), then go back around and do more stuff to them
(build up a lot of cross-thread entropy), in a multi-core environment, making
sure that I pack() the thing before finishing my changes.

The same thing I'd do to construct any thread-coordination bug. Of course,
the nature of thread bugs is that they are never guaranteed to show up, even
when present, so I'd run the thing on a multi-core machine to increase the
likelihood of cross-thread inconsistency.

That's the idea that passage gave me, anyway.

I'm not against doing work, and believe me I've done plenty in my
question to get my Java code to work correctly. But when I know the
answer to a question, I don't sit around telling the person asking the
question "I know the answer, but I refuse to tell you, or even help you
understand how to find the answer from the resources you've been
offered". I help the person learn the answer.

When have I ever done that? In the first place, I've never claimed to "know
the answer", instead I pointed you to well-established authorities (e.g., Sun)
who do know the answer. Then you come back and mischaracterize my comments,
and wonder why I call that "snarky".

Nor have I "refused[d] to even help you understand how to find the answer from
the resources you've been offered". /Au contraire/ I have tried repeatedly to
explain how I read these sources, find new sources that confirm the
conclusion, point out how authoritative those sources are, and draw together
information provided by other respondents with the hints that I've repeatedly
researched for you.

So don't straw-man my points by claiming that I claimed to "know the answer"
or get on my case because the resources I find don't speak to you as clearly
as they do to me. I have freely admitted the limits of my knowledge, and I
continue to refer you to more authoritative sources.

If you don't think *Sun* has made the case strongly enough, well, that's
hardly my fault.

I have already read the references offered and not found the information
I seek. You claim the information is there and imply that it's easily
accessible. If it's so easy, why not just say so? Why waste so much
time refusing to help, when you could instead use that time productively
by helping?

Productively for whom? I have tried to help by providing authoritative
sources, as have many others here. You misrepresent my points - I never said
the information was "there and ... easily accessible", only that it's
unequivocal and authoritative and provides hints as to how to construct the
example you keep stubbornly demanding. Somehow I am to be responsible for
your inaccurate representation of what I said?

So, either you don't actually know the answer (which is fine, though you
should just admit it so we can forget about worrying whether you'll
share it), or you do. If you do, it's incredibly useless for you to
pretend that you're interested in helping people when at the same time
you refuse to.

And you say you aren't being snarky. Sheesh.

All I've claimed to know is that authorities from Sun on down have indicated
the dangers of not respecting the multi-threaded nature of the GUI lib. It is
only you who misrepresents my comments as claiming to "know the answer" - the
only answer I claim to know is that it's dangerous to initialize Swing
components off the EDT. I claimed to know that it could cause controls not to
appear on the screen, a claim borne out by the experience of other respondents
on this thread and by the sources cited by those respondents. That claim has
been substantiated. I claimed to know that Google and other searches will
turn up more information, a claim I and others have substantiated by
continuing to search and find references that support the point as you
continue to reject the information we provide. I claim to have found hints on
how to construct examples of this problem, I claim I substantiated /supra/.

It is utterly unfair of you to say I claimed to "know the answer" to your
limited and to my mind superfluous demand for a pre-constructed example.
Certainly many others have chimed in on that question, so why should I retread
what they've said?

You should incorporate the gestalt of the answers the group is providing here.
I feel no need to rehash a point that another has made, such as that
synchronization issues are next to impossible to reproduce reliably and that
seeming to work is no guarantee that code is correct. I'm reading the answers
that others are giving you - and guess what? They're giving you the exact
same advice as I am, with even stronger evidence and more concrete examples.
So why is my advice wrong?

Please be fair.

 

[Daniel Pitts]

[...]
I know what *might* go wrong - you might have an improper value
displayed in a control, for example. You might have a control not be
visible at all - it depends on the work that's being done.

How could those things happen? Specifically, that is, how could those

One of many possible ways is that data isn't automatically shared across
threads. Threads may have their own "local" memory, so some data is in
shared memory space, and other data are only in the local memory space.
This can lead to strange problems.

 

[Peter Duniho]

[...]
Two things you are surely aware of are:

[snip]

Yes, I'm aware of all that.

So... whatever knowledge you gain here, in my humble opinion,
is next to useless.

All due respect, it's my belief that there's no such thing as "useless
knowledge".

I may have no practical use for the information, but I've found that the
more I know, the more I can do. Even if the information isn't applicable
in the scenario in which is seems specifically tied to, it often winds up
useful in other contexts.

Basically, if there's a way to break something, then to me that's
interesting and informative. It tells me a lot about how something works
to know how you can break it, and knowing how something works is always
better (for me) than not knowing how something works.

There are, of course, other ways to approach the question of how something
works, but knowing how to break something is often a more direct and
efficient way to learn what's _most_ interesting about something, without
having to go through the effort of a thorough analysis of the thing (for
example, I'd guess that since Sun's Java is now open source, I could just
spend some time sifting through the source code...but doing that, I will
spend a lot of time looking at uninteresting things).

This approach works for all sorts of things, not just software. But it's
most practical in the realm of software since you can break something
without ruining it.

[...]
So... it's really a pragmatic issue: do you spend a week chasing
shadows and learn something useless, or just stick to the principle.

For me, it's not an either/or proposition.

I respect that not everyone may agree that this is a useful way to seek
knowledge. But for anyone who would criticize me for following what has
been for me a decades-old, very successful approach to learning, I don't
respect that at all and would ask such persons to withhold their unwanted
criticisms of the approach.

Pete

 

[Peter Duniho]

That is because support is only for HTML 3.2, which didn't have
&mdash; . It has nothing to do with the OS or font encoding; you
can't use it on Java for Windows either.

That's a popular theory...I've seen it myself on the Apple Java-dev
mailing list.

But, there are lots of things from HTML 4.01 that work fine, such as
CSS2.0 style settings. And you're wrong that I can't use it on Java for
Windows. One of the first things I tried when it didn't work on the Mac
was to take the same program and run it on Windows. It worked fine.

Supporting only HTML 3.2 might be the _excuse_ being used by Apple, but it
doesn't coincide with the rest of their HTML user client implementation
here. The only significant thing I've run into that seems to be missing
are these character entities. Other "modern" HTML constructs are in fact
supported, in spite of not being valid for a 3.2 HTML document.

Pete

 

[Larry A Barowski]

That's a popular theory...I've seen it myself on the Apple Java-dev
mailing list.

But, there are lots of things from HTML 4.01 that work fine, such as
CSS2.0 style settings. And you're wrong that I can't use it on Java for
Windows. One of the first things I tried when it didn't work on the Mac
was to take the same program and run it on Windows. It worked fine.

Supporting only HTML 3.2 might be the _excuse_ being used by Apple, but it
doesn't coincide with the rest of their HTML user client implementation
here. The only significant thing I've run into that seems to be missing
are these character entities. Other "modern" HTML constructs are in fact
supported, in spite of not being valid for a 3.2 HTML document.

I suspect this is related to the Java version rather than the
OS. From the versions I have at hand, I see that &mdash; is
not supported on Java 1.5.0_14 or the latest 1.7.0 ea for
Windows, but is supported under 1.6.1_01. Since they
promise only HTML 3.2 support, using anything newer is
risky.

 

[John W. Kennedy]

I don't know if it'll help, but a few years back (on 1.4) I had an
application that started to appear completely blank after startup until
the main window was resized, after which it appeared to work normally
(no deadlock). The application did a lot of GUI initialization in the
sense that it would construct the component tree with minimal
initialization of each component and then, before making the root
visible, recursively run through all the components setting attributes
(including layout manager setup) according to a configuration.

And I had a program that /always/ froze after running the splash (which
had progress bars) if it was running on a Mac. Putting it all into an
invokeLater fixed it. Easy-peasy.



--
John W. Kennedy
"There are those who argue that everything breaks even in this old dump
of a world of ours. I suppose these ginks who argue that way hold that
because the rich man gets ice in the summer and the poor man gets it in
the winter things are breaking even for both. Maybe so, but I'll swear I
can't see it that way."
-- The last words of Bat Masterson

 

[Gordon Beaton]

I'd be interested in a reference for that. Can you remember where you
read it?

http://en.wikipedia.org/wiki/Therac-25 summarizes and has links to
further reading, all of it interesting.

Actually the manufacturer *claimed* that it had been extensively
tested, but that wasn't really the case.

/gordon

--

 

[Philipp]

Case and point, there was once an automated medical scanning device that
worked 99.9% of the time, but there were a few accidents that no one
could figure out what happened. A few patients died from over-exposure
to radiation. This product of course had been extensively tested and
retested, and worked for so much of the time, but due to a race
condition it could fail (catastrophically) in an unexpected way.

I'd be interested in a reference for that. Can you remember where you
read it?
Thanks Phil

 

[Lew]

http://en.wikipedia.org/wiki/Therac-25 summarizes and has links to
further reading, all of it interesting.

Actually the manufacturer *claimed* that it had been extensively
tested, but that wasn't really the case.

The original article describing the details of the case was published in the
IEEE publication /Computer/ in the early 90s, IIRC. (The article is
referenced from the Wikipedia link.) It was written in a dry, dispassionate
and objective style that made the account all the more chilling for its
refusal to sensationalize.

The manufacturer didn't start claiming that it fixed the problem until enough
people found out that there was a problem; originally they suppressed the
information. Once they were called to account, they were fond of rapidly
responding with bizarre claims like "reliability has been improved 5000%".
Aside from the meaninglessness of such statements absent any baseline
measurement of "reliability", it is clear the manufacturer actually did
nothing to solve the problem except try to hide it and let people die.