This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: malloc() and spinlocks
- From: Lubos Lunak <l dot lunak at suse dot cz>
- To: Wolfram Gloger <Wolfram dot Gloger at dent dot med dot uni-muenchen dot de>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Tue, 3 Dec 2002 11:25:08 +0100
- Subject: Re: malloc() and spinlocks
- References: <200211251733.14550.l.lunak@suse.cz> <20021126150223.D1310@sunsite.ms.mff.cuni.cz> <200211261412.PAA22679@max.zk-i.med.uni-muenchen.de>
On Tuesday 26 of November 2002 15:12, Wolfram Gloger wrote:
> > Isn't it better to have the fast inline non-recursive mutices provided
> > for _LIBC only use by the threading library (this could be something like
> > lll_mutex_lock for nptl and something similar for linuxthreads)?
>
> I agree it would be better to have this in a more general form. If
> you (or anyone) provide(s) a patch with lll_mutex_lock... etc. macros,
> I'll gladly adapt thread-m.h.
>
> > The spinlocks below inline quite a lot of code, ideally it should be just
> > lock; xaddl; testl; jne lab_in_other_subsection
>
> I believe only mutex_lock is non-optimal and inlines a sizeable piece
> of code. But it would be good to have this for non-i386 architectures
> too.
Could you please enable the spinlocks for x86 now, before it gets forgotten?
I don't care what kind of locking will be there, but webcvs still shows no
change, so the slow mutexes are still used.
Thanks
--
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/