 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Michael D. Crawford
Guest
|
 Posted: Thu Nov 03, 2005 1:02 pm Post subject: Sermon at the Soup Kitchen |
 |
|
Friends,
I'd like your expert opinions on a C++ article I'm writing. I plan to
submit it in a few hours to the community website Kuro5hin
([url]http://www.kuro5hin.org/)[/url]. I'll leave it in "edit mode" until
tomorrow, so I'll still have time to revise it to reflect your comments.
From my introduction:
"When I talk to those guys about how to write better code I have the
sense that their experience of me is like going to church."
"Many people go to church. How many are without sin?"
"But I didn't learn to preach because I studied at the seminary. It
is because I was a derelict on skid row until I was saved by..."
"... smart pointers and automated testing."
Sermon at the Soup Kitchen
On C++ Software Quality and Institutional Resistance to Change
http://www.goingware.com/tips/smart-pointers-and-automated-testing/
My questions:
1. I was hired specifically to revamp the company's software
development methodology so they could achieve high reliability, as even
a single incident of failure of their Computer Aided Design product
could cost end-users as much as a million dollars if the products
designed by it failed to work as designed when manufactured. But when
the chips were down, "Yoyodyne" founder "Jack" ordered everyone, me
included, to cut corners so we could implement features faster. This
led to my ultimatum quoted in the article. I'm now looking for a new job.
My question for you is, given that Jack was not a programmer, and didn't
have the first clue about how to achieve software quality (nor did the
rest of the staff), how could I have overcome the company's resistance
to change in such a way that it wouldn't have come to an ultimatum?
2. I have a few links to smart pointer and automated testing pages
early in the article, but not many. Can you suggest others? I'm
especially interested to hear about other test frameworks, not just for
C++ but for *any* language, so that people who don't use C++ still have
something to gain by reading my piece. How about frameworks for other
kinds of testing than unit testing, like acceptance or integration testing?
3. Can you pick any nits with my assertions about C++ or the various
smart pointers? Do you agree with me that the following is a case where
auto_ptr is the best choice? Can you think of others?
http://www.goingware.com/tips/smart-pointers-and-automated-testing/#when-to-use-auto_ptr
4. I say early on that neither auto_ptr nor the Boost smart pointers
provide all the different kinds of smart pointers one would want. What
other kinds can you think of? How would they be implemented? I already
have a couple completely implemented, and keep thinking of more, but I'd
like ideas for others to discuss in my next installment. I won't tell
you my answers yet because I want to stimulate discussion.
I'll be placing all my smart pointers under the Boost license and
posting a tarball on my website. I've already invited the Boost list to
add them to Boost, but if they don't want them, I'll host them at
Sourceforge.
5. I've already been over my article several times looking for grammar
and spelling errors, but if you can still find any, please let me know.
6. If you were a sinner before you came to my soup kitchen's service,
have I saved your soul? If not, how could I have made my case more
effectively? Was your free, hot supper satisfying? Would you come back
for more?
My article is going to appear in two or three installments at Kuro5hin.
The next one, yet to be written, will cover automated testing. I'm
also going to cover exception safety, which I feel I have finally come
to understand. Depending on how long the second installment is,
exception safety might appear there, or in a third installment. I'll
discuss the connection between RAII, smart pointers and exception safety.
As I deliver each sermon, I'll add it at the link above. Look for them
in the table of contents, quoted below.
* How I Was Saved
o Smart Pointers
o Automated Testing
* Ultimatum
* auto_ptr and Its Alternatives
o auto_ptr Doesn't Work for Arrays
o Take My Memory. Please!
o The Simple Solution
o Standard Template Library-Compatible Smart Pointers
o That's Great! Is It Thread-Safe Too?
o But Arrays? What About the Arrays?
o So is auto_ptr Completely Useless?
o Without Further Ado
* The Right Tool for the Job
Thanks for your help!
--
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[email]crawford (AT) goingware (DOT) com[/email]
Tilting at Windmills for a Better Tomorrow.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
David Abrahams
Guest
|
| Posted: Thu Nov 03, 2005 7:34 pm Post subject: Re: Sermon at the Soup Kitchen |
|
|
"Michael D. Crawford" <crawford (AT) goingware (DOT) com> writes:
| Quote: | I'll be placing all my smart pointers under the Boost license and
posting a tarball on my website. I've already invited the Boost list to
add them to Boost, but if they don't want them, I'll host them at
Sourceforge.
|
It doesn't work that way. Proposed libraries are accepted into Boost
only after undergoing a formal review.
http://www.boost.org/more/formal_review_process.htm
If your smart pointers aren't in the next Boost release, it's not
because "we didn't want them," it's because you haven't gone through
the process and been accepted.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Michael D. Crawford
Guest
|
| Posted: Fri Nov 04, 2005 10:59 am Post subject: Re: Sermon at the Soup Kitchen |
|
|
David Abrahams wrote:
| Quote: | I'll be placing all my smart pointers under the Boost license and
posting a tarball on my website. I've already invited the Boost list to
add them to Boost, but if they don't want them, I'll host them at
Sourceforge.
It doesn't work that way. Proposed libraries are accepted into Boost
only after undergoing a formal review.
|
I understood that, but the reason I thought they might not want them is
that they might not feel that they were useful, and not because they
weren't good enough to withstand review.
I expect I need to do some work to improve my templates. They are unit
tested, but that's about it so far.
The reason one might not feel them to be useful is that they are mostly
bottlenecks for assertions. The help one debug and test code, but in
some cases, have no effect whatsoever on debug builds.
Here is one thing I my code does: whenever given a non-NULL pointer, or
any reference, it reads its first byte. If the addressed was unmapped,
there will be a segment violation. Even if the memory is mapped, but
you are testing under valgrind, Purify or Spotlight, and the memory is
out of bounds, then a memory debugger will catch the error.
I've used this a great deal in the past. It's a very powerful debugging
technique.
Best,
--
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[email]crawford (AT) goingware (DOT) com[/email]
Tilting at Windmills for a Better Tomorrow.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Howard Hinnant
Guest
|
|
| Back to top |
|
|
David Abrahams
Guest
|
| Posted: Sat Nov 05, 2005 11:37 am Post subject: Re: Sermon at the Soup Kitchen |
|
|
"Michael D. Crawford" <crawford (AT) goingware (DOT) com> writes:
| Quote: | David Abrahams wrote:
I'll be placing all my smart pointers under the Boost license and
posting a tarball on my website. I've already invited the Boost list to
add them to Boost, but if they don't want them, I'll host them at
Sourceforge.
It doesn't work that way. Proposed libraries are accepted into Boost
only after undergoing a formal review.
I understood that, but the reason I thought they might not want them is
that they might not feel that they were useful, and not because they
weren't good enough to withstand review.
|
Maybe, but I didn't want the wrong impression to be left with the NG
at large. We often get the question, "why is Joe Guru's SuperTemplate
library not in Boost?" Usually the answer is a question: "has anyone
submitted a proposal?"
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Joe Seigh
Guest
|
| Posted: Sat Nov 05, 2005 11:39 am Post subject: Re: Sermon at the Soup Kitchen |
|
|
Michael D. Crawford wrote:
| Quote: | Friends,
I'd like your expert opinions on a C++ article I'm writing. I plan to
submit it in a few hours to the community website Kuro5hin
([url]http://www.kuro5hin.org/)[/url]. I'll leave it in "edit mode" until
tomorrow, so I'll still have time to revise it to reflect your comments.
[...]
As I deliver each sermon, I'll add it at the link above. Look for them
in the table of contents, quoted below.
* How I Was Saved
o Smart Pointers
o Automated Testing
* Ultimatum
* auto_ptr and Its Alternatives
o auto_ptr Doesn't Work for Arrays
o Take My Memory. Please!
o The Simple Solution
o Standard Template Library-Compatible Smart Pointers
o That's Great! Is It Thread-Safe Too?
o But Arrays? What About the Arrays?
o So is auto_ptr Completely Useless?
o Without Further Ado
* The Right Tool for the Job
|
Thread safety of smart pointers has been discussed before. The refcounted
stuff in C++/Boost probably isn't really thread safe even for the "threadsafe
as int" case, i.e. missing release membar on dereferencing a const object.
For atomic thread safety you can look at http://atomic-ptr-plus.sourceforge.net/
and there's support in the Linux kernel for atomically thread safe refcounting
using RCU and an "increment if not zero" interlocked primative which comes
in real handy. You can also use hazard pointers instead of RCU to safely
increment the reference count and there was some discussion on using deferred
reference counting for this also if you don't mind the "stop the world" GC
involved needed to safely examine thread stacks.
--
Joe Seigh
When you get lemons, you make lemonade.
When you get hardware, you make software.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Peter Dimov
Guest
|
| Posted: Sat Nov 05, 2005 6:42 pm Post subject: Re: Sermon at the Soup Kitchen |
|
|
Joe Seigh wrote:
| Quote: | Thread safety of smart pointers has been discussed before. The refcounted
stuff in C++/Boost probably isn't really thread safe even for the "threadsafe
as int" case, i.e. missing release membar on dereferencing a const object.
|
Why do you need a release barrier on dereferencing a const object?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
David Abrahams
Guest
|
| Posted: Sun Nov 06, 2005 12:11 pm Post subject: Re: Sermon at the Soup Kitchen |
|
|
Joe Seigh <jseigh_01 (AT) xemaps (DOT) com> writes:
| Quote: | Thread safety of smart pointers has been discussed before. The
refcounted stuff in C++/Boost probably isn't really thread safe even
for the "threadsafe as int" case, i.e. missing release membar on
dereferencing a const object.
|
?? You can't dereference an int.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Joe Seigh
Guest
|
| Posted: Sun Nov 06, 2005 12:15 pm Post subject: Re: Sermon at the Soup Kitchen |
|
|
Peter Dimov wrote:
| Quote: | Joe Seigh wrote:
Thread safety of smart pointers has been discussed before. The refcounted
stuff in C++/Boost probably isn't really thread safe even for the "threadsafe
as int" case, i.e. missing release membar on dereferencing a const object.
Why do you need a release barrier on dereferencing a const object?
|
For those architectures or complers where stores can pass loads. The object
can be deleted and possible reused before read access has completed. Release
semantics rather than release membar is probably a better way of designating
it since not all architectures or compilers will require explicit action.
--
Joe Seigh
When you get lemons, you make lemonade.
When you get hardware, you make software.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
jimmaureenrogers@worldnet
Guest
|
| Posted: Sun Nov 06, 2005 12:16 pm Post subject: Re: Sermon at the Soup Kitchen |
|
|
Peter Dimov wrote:
| Quote: | Joe Seigh wrote:
Thread safety of smart pointers has been discussed before. The refcounted
stuff in C++/Boost probably isn't really thread safe even for the "threadsafe
as int" case, i.e. missing release membar on dereferencing a const object.
Why do you need a release barrier on dereferencing a const object?
|
Is it possible for some thread to try to dereference the const object
before it is
completely initialized? If so, a release barrier is a good idea.
Jim Rogers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Peter Dimov
Guest
|
| Posted: Mon Nov 07, 2005 12:25 am Post subject: Re: Sermon at the Soup Kitchen |
|
|
[email]jimmaureenrogers (AT) worldnet (DOT) att.net[/email] wrote:
| Quote: | Peter Dimov wrote:
Joe Seigh wrote:
Thread safety of smart pointers has been discussed before. The refcounted
stuff in C++/Boost probably isn't really thread safe even for the "threadsafe
as int" case, i.e. missing release membar on dereferencing a const object.
Why do you need a release barrier on dereferencing a const object?
Is it possible for some thread to try to dereference the const object
before it is completely initialized? If so, a release barrier is a good idea.
|
No, this is not possible. The sequence is:
construct a X on the heap
construct a shared_ptr pointing to the X
pass this shared_ptr to another thread
access X
The "pass to another thread" operation provides serialization. This
isn't shared_ptr-specific, the scenario is the same when using X*.
In addition, if it were possible, a release barrier in *p won't have
helped.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Joe Seigh
Guest
|
| Posted: Mon Nov 07, 2005 9:35 am Post subject: Re: Sermon at the Soup Kitchen |
|
|
[email]jimmaureenrogers (AT) worldnet (DOT) att.net[/email] wrote:
| Quote: | Peter Dimov wrote:
Joe Seigh wrote:
Thread safety of smart pointers has been discussed before. The refcounted
stuff in C++/Boost probably isn't really thread safe even for the "threadsafe
as int" case, i.e. missing release membar on dereferencing a const object.
Why do you need a release barrier on dereferencing a const object?
Is it possible for some thread to try to dereference the const object
before it is
completely initialized? If so, a release barrier is a good idea.
|
With "thread-safe as int" you need to own the object in question so for
shared objects with threading that means locks which have the requisite
release semantics for modifying objects. For const objects, where you
copy a pointer to the object, used by some String implementations, you
have proper acquire semantics by virtue of the ownership mechanism. It's
using the pointer to a const object after you've released ownership, e.g.
a lock or something, where you get into trouble since on some architectures
stores can pass loads and the object can be deleted by another thread
before all accesses to the object complete.
--
Joe Seigh
When you get lemons, you make lemonade.
When you get hardware, you make software.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Peter Dimov
Guest
|
| Posted: Mon Nov 07, 2005 9:37 am Post subject: Re: Sermon at the Soup Kitchen |
|
|
Joe Seigh wrote:
| Quote: | Peter Dimov wrote:
Joe Seigh wrote:
Thread safety of smart pointers has been discussed before. The refcounted
stuff in C++/Boost probably isn't really thread safe even for the "threadsafe
as int" case, i.e. missing release membar on dereferencing a const object.
Why do you need a release barrier on dereferencing a const object?
For those architectures or complers where stores can pass loads. The object
can be deleted and possible reused before read access has completed.
|
This is handled by the acquire/release protocol in the refcount
decrement.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
jimmaureenrogers@worldnet
Guest
|
| Posted: Mon Nov 07, 2005 10:51 am Post subject: Re: Sermon at the Soup Kitchen |
|
|
Peter Dimov wrote:
| Quote: | jimmaureenrogers (AT) worldnet (DOT) att.net wrote:
Is it possible for some thread to try to dereference the const object
before it is completely initialized? If so, a release barrier is a good idea.
No, this is not possible. The sequence is:
construct a X on the heap
construct a shared_ptr pointing to the X
pass this shared_ptr to another thread
access X
|
Your sequence works for local const objects.
How does it work for global const objects?
Exactly when are globals and statics initialized, with relation to
threads?
Which thread initializes globals?
Are globals always initialized when only one thread is running, and
before any additional threads can be executed?
What happens when the global const object is a compound type
rather than a primitive with atomic operations?
How long does it take to initialize a non-atomic const object?
During that initialization, what are the guarantees that some
other thread will not attempt to access the values in the
const object?
I believe the answer is that those details are not defined by the
language since the C++ standard does not currently deal with
threads.
Jim Rogers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Joe Seigh
Guest
|
| Posted: Mon Nov 07, 2005 2:23 pm Post subject: Re: Sermon at the Soup Kitchen |
|
|
Peter Dimov wrote:
| Quote: | Joe Seigh wrote:
Peter Dimov wrote:
Why do you need a release barrier on dereferencing a const object?
For those architectures or complers where stores can pass loads. The object
can be deleted and possible reused before read access has completed.
This is handled by the acquire/release protocol in the refcount
decrement.
|
Even for the lock-free version? My impression from discussions on
COW strings with lock-free reference counting was they thought
release memory barriers weren't needed since the string buffers
were immutable.
--
Joe Seigh
When you get lemons, you make lemonade.
When you get hardware, you make software.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
