> > 1.6. New patch to follow.
> >
> > The current S_LOCK and TAS() implementations (my patch of late May) are
> > slower than they need to be and cause more code bloat than they need to.
> > The bloat is caused by using a macro to inline a relatively complex bit
> > of code that is only used in the blocked lock case. I suspect the slowness
> > is caused at least partly by the macro as it requires more registers.
> >
> > I have developed a new patch that separates out the lock available case
> > from the busywaiting case and that uses the GCC _inline_ facilty to make
> > the asm interface still look as clean as a function while not costing
> > anything. For a preview, see
>
> Quite and analysis. I want to comment on the code more, but I just want
Please do. I am very interested in reactions or followup investigations.
> to point out now that many of our i386 platforms are not GNU. I think
> we have to use macros. I can't think of any GNU-specific code in the
> source tree at this point, and I don't think it makes sense add it now
> just to make the code look a litter cleaner.
Most of the original tas() __asm__() implementations are GCC specific. This
includes all the Linux platforms except PPC, all the *BSD platforms, even the
VAX. GCC is also fairly commonly used even on the commercial OSes.
As far as I can tell, the only C coded platforms that are not GCC specific
are SCO i386 and SunOS/Solaris on Sun3 and Sparc. The other non-GCC platforms
have external tas.s function implementations (HP), or have system specific
calls (AIX, OSF, SGI, Nextstep).
Finally, the difference between a tas() function implementation and the best
possible inline implementation appears to be only 0.06 microseconds on a P133.
This will add 0.0003 seconds to startup. On SCO only. On Sparc this is a leaf
call and possibly even cheaper. No other platforms are affected.
Remember also that I am adding two features that previously did not exist,
backoff, and stuck lock detection.
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
"If you lie to the compiler, it will get its revenge." -- Henry Spencer
