This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Make generic atomicity.h use gthr.h mutexes


On Thu, Nov 07, 2002 at 10:47:24PM -0500, Phil Edwards wrote:
> 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.

Right.  I'm not sure one is really better than the other, aside from
some vague emotional satisfaction.  It's the same kind of selective
blindness that says it's OK to have an iostreams implementation 300 
times slower than the others as long as it appears to satisfy the 
standard.
 
> > 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 possible to run threads safely in a system with a non-thread-safe 
string implementation.  It might even be the common case on such 
systems.  Embedded system developers are used to working with 
documented limitations.  What they need is a warning, and where
possible, a choice.

> > > 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...)

ios_base callbacks are essential for nontrivial operators << and >>.
Such usage is properly buried in implementation code, so it's no 
surprise that we don't notice it much.

> > > 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.

As noted, not using strings and iostreams in multiple threads is a 
very different thing from not using multiple threads at all.

Nathan Myers
ncm at cantrip dot org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]