Make generic atomicity.h use gthr.h mutexes
Phil Edwards
phil@jaj.com
Thu Nov 7 19:47:00 GMT 2002
On Thu, Nov 07, 2002 at 08:39:02PM +0000, Nathan Myers wrote:
> > We wouldn't be pretending; the operations are atomic from an outsider's
> > point of view. Not at the instruction level, but still correct.
>
> We'd be pretending to have built a practical library.
We've /been/ pretending to have built a functionally correct library.
> One of the key insights embodied in the STL is that performance
> is as important a part of an abstraction as the results.
*shrug* I don't give a rat's ass how fast I get the wrong answers.
> > it's very possible that atomicity.h will get used
> > outside of the string class.
>
> Good point, but it isn't used anywhere else yet, to my knowledge.
I knew that parts of stl_threads.h were commented as "could be redone
to use atomicity.h," but I too thought that they weren't actually used
elsewhere. Turns out they're used at least in ios_base, handling callbacks.
(Talk about a rarely-used feature...)
> > I'd recommend at least a configure test,
> > if threads are enabled but the generic model is used, to print a warning
> > saying that these operations will be slow.
> >
> > (How slow are we talking? Give me a test case, I'll run it with both
> > models. I don't think these functions are called that often.)
>
> They are called every time an empty string is created, any time a
> string is copied, and any time a string is destroyed.
Not all that often, then, compared to other string operations.
> > > I agree that quietly building something broken, as we do now, might
> > > be worse.
> >
> > /Might/?
>
> Yes. It's just a different kind of broken.
If the user feels that correct operation is too slow, then --disable-threads
will turn the mutex calls into no-ops, and the memory writes will be
non-atomic, which is exactly what we have now.
Phil
--
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
- Edsger Dijkstra, 1930-2002
More information about the Libstdc++
mailing list