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

[Daniel Jacobowitz <drow at mvista dot com>]

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.
> 
> 
> > I wouldn't
> > object to additional configure option, e.g. --very-slow-threadsafe-string
> > and --thread-unsafe-string to be used to make it build anyway.
> 
> Dunno about options (and it's very possible that atomicity.h will get used
> outside of the string class).  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 aren't, and these are generally uncontested locks.  It would be
nice if the mutex were part of the _Atomic_Word but see my discussion
with Richard Earnshaw about ARM atomic ops a couple of weeks ago for
some of the difficulties.

> > I agree that quietly building something broken, as we do now, might be worse.
> 
> /Might/?

_Absolutely_ seconded.  Having been bitten by this...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer