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