Peter Dimov saved me from a collosal blunder by correcting my impression that shared_ptr wasn't thread-safe. I've posted a revised draft here: http://www.goingware.com/tips/smart-pointers-and-automated-testing/#thread-s... I hadn't previously understood that thread-safety is not an all or nothing proposition, that is, that one can only guarantee that certain kinds of simultaneous operations will work. My revised text points that out and quotes the first paragraph of shared_ptr's doc on thread safety. I *did* know that there are different degrees of exception safety, so I compare thread-safety guarantees to that. When I cover exception safety in a week or so I'll discuss what that means; sometimes for reasons of performance or memory conservation, one must choose not to be completely exception-safe. Sermon at the Soup Kitchen http://www.goingware.com/tips/smart-pointers-and-automated-testing/ It's going to be about three hours before I post the final section and submit to Kuro5hin. My first try at "The Right Tool for the Job" in my Kuro5hin diary was characterized by one K5 member as "Utterly incomprehensible", and I realize now he's absolutely correct, so I need to address that. I'm going to add a small section to it that I think I'll call "Every Engineer's Solemn Duty" that exhorts the reader to do the right thing when his company plows ahead with a disastrous engineering decision, even if one risks losing one's job, getting blacklisted, sued or even imprisoned. I don't think most engineers ever spend much time thinking about such things until they are suddenly faced with actually making the awful decision to issue an ultimatum, as I did, or blow the whistle, as I still might. I'm lucky I only lost my job. Think of the poor Morton Thiokol engineer who didn't trust his conscience when he knew the Space Shuttle's O-rings had frozen. He settled for reporting the risk of explosion through company channels, and trusted that Morton Thiokol would do the right thing. By not raising Hell and going directly to NASA when he realized the launch hadn't been canceled, he allowed seven people to lose their lives, a billion dollar spacecraft to be destroyed, and the US space program to be set back several years. If I can find a good web page about it, I'm also going to mention the Ford Pinto's exploding gas tank. It came out in a lawsuit that Ford's engineers made a calculated decision to let the gas tank go ahead and explode because they didn't think the cost of paying the inevitable lawsuit damages would be as much as the added manufacturing costs of a safer tank. Before quitting it to run "Yoyodyne" full time, "Jack's" last job was managing a team designing a novel, experimental new medical device, the failure of which would doom the patient to certain death within minutes. I might send a link to "Sermon at the Soup Kitchen" to his ex-employer, along with an explanation of just who Jack and Yoyodyne really are. And yes, I'm well aware that if Jack ever reads my sermons he might try to drag me into court. At least I can sleep soundly at night. You should see all the emails I *don't* post online. Yours, -- Michael D. Crawford
On Wed, 02 Nov 2005 18:50:38 -0400, Michael D. Crawford wrote Just a point of moderation here -- aside from the question about shared_ptr these posts seem mostly off-topic for this list. I would suggest critiques of the article go off-list somewhere else -- like directly to Michael....
...snip long post...
I'm lucky I only lost my job. Think of the poor Morton Thiokol engineer who didn't trust his conscience when he knew the Space Shuttle's O-rings had frozen. He settled for reporting the risk of explosion through company channels, and trusted that Morton Thiokol would do the right thing. By not raising Hell and going directly to NASA when he realized the launch hadn't been canceled, he allowed seven people to lose their lives, a billion dollar spacecraft to be destroyed, and the US space program to be set back several years.
And now for one really off-topic comment ;-) Not sure it was the same engineer, but I read that one of the Morton Thiokol engineers committed suicide later after not being able to convince management to stop the launch -- he knew the launch was doomed. You also might want to check out Edward Tufte's Visual Explanations. He describes why the charts the engineers used to communicate the issues to management were completely ineffective in communicating the obvious peril of launching at a temperature 25 degrees F lower than the temperature of any other launch. A basic scatterplot of the right data would likely have prevented the whole accident. With software, things are rarely this clear... Jeff
"Michael D. Crawford" <crawford@goingware.com> writes:
I *did* know that there are different degrees of exception safety, so I compare thread-safety guarantees to that. When I cover exception safety in a week or so I'll discuss what that means; sometimes for reasons of performance or memory conservation, one must choose not to be completely exception-safe.
Sorry, but that's ridiculous. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Michael D. Crawford" <crawford@goingware.com> writes:
I *did* know that there are different degrees of exception safety, so I compare thread-safety guarantees to that. When I cover exception safety in a week or so I'll discuss what that means; sometimes for reasons of performance or memory conservation, one must choose not to be completely exception-safe.
Sorry, but that's ridiculous.
At first I interpretted Michael's statement to mean that sometimes you might reasonably choose not to meet even the basic exception-safety guarantee. But maybe by "completely exception-safe" Michael means the "no-throw" guarantee, in which case there may be all sorts of reasons, depending on the circumstances, not to be completely exception-safe, no? -- Jonathan Turkanis www.kangaroologic.com
"Jonathan Turkanis" <technews@kangaroologic.com> writes:
David Abrahams wrote:
"Michael D. Crawford" <crawford@goingware.com> writes:
I *did* know that there are different degrees of exception safety, so I compare thread-safety guarantees to that. When I cover exception safety in a week or so I'll discuss what that means; sometimes for reasons of performance or memory conservation, one must choose not to be completely exception-safe.
Sorry, but that's ridiculous.
At first I interpretted Michael's statement to mean that sometimes you might reasonably choose not to meet even the basic exception-safety guarantee. But maybe by "completely exception-safe" Michael means the "no-throw" guarantee, in which case there may be all sorts of reasons, depending on the circumstances, not to be completely exception-safe, no?
Maybe I was a bit too abrupt, but, no. IMO, nobody who writes "not completely exception safe" as a shorthand for "only provides the basic guarantee" should be writing about exception safety. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Jonathan Turkanis" <technews@kangaroologic.com> writes:
David Abrahams wrote:
"Michael D. Crawford" <crawford@goingware.com> writes:
I *did* know that there are different degrees of exception safety, so I compare thread-safety guarantees to that. When I cover exception safety in a week or so I'll discuss what that means; sometimes for reasons of performance or memory conservation, one must choose not to be completely exception-safe.
Sorry, but that's ridiculous.
At first I interpretted Michael's statement to mean that sometimes you might reasonably choose not to meet even the basic exception-safety guarantee. But maybe by "completely exception-safe" Michael means the "no-throw" guarantee, in which case there may be all sorts of reasons, depending on the circumstances, not to be completely exception-safe, no?
Maybe I was a bit too abrupt, but, no. IMO, nobody who writes "not completely exception safe" as a shorthand for "only provides the basic guarantee" should be writing about exception safety.
I didn't mean to suggest that the terms *should* be used interchangeably. -- Jonathan Turkanis www.kangaroologic.com
participants (4)
-
David Abrahams -
Jeff Garland -
Jonathan Turkanis -
Michael D. Crawford