This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Make generic atomicity.h use gthr.h mutexes
On Thu, Nov 07, 2002 at 02:21:53PM -0500, Phil Edwards wrote:
> On Thu, Nov 07, 2002 at 05:37:13PM +0000, Nathan Myers wrote:
> > I have strong doubts about this approach. The library would pass tests
> > but the performance would be prohibitively bad. It would be better to
> > refuse to build, under configure options implying threading and no
> > instruction-level atomicity is available, than to pretend.
>
> 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.
One of the key insights embodied in the STL is that performance
is as important a part of an abstraction as the results.
> > I wouldn't
> > object to additional configure options, e.g.
> > --very-slow-threadsafe-string and --thread-unsafe-string to be
> > used to make it build anyway.
>
> 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'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.
> > I agree that quietly building something broken, as we do now, might
> > be worse.
>
> /Might/?
Yes. It's just a different kind of broken.
Nathan Myers
ncm-nospam@cantrip.org