This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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: malloc() and spinlocks


Ok, we're talking about the single-threaded (i.e. not linked against
libpthread) case only.  The large benefits for the threaded case
should be clear.  That is actually what I meant, sorry for being a
little unclear.

> ?? Without thread-m.h assembly spinlocks the code is:
> 
> movl pthread_mutex_lock@GOT(%ebx), %eax
> testl %eax, %eax
> jne 1f
> movl $1, %eax
> movl %eax, mutexvar@GOTOFF(%ebx)
> .subsection 1
> 1: something for -lpthread
> .previous
> 
> Your spinlock code is longer,

Sure, but is it really considerably slower in the single-threaded
case?  I'll make measurements tonight.  Basically we have one
zero-comparison and one movl vs. one xchgl and one zero-comparison.

> even if I change if (!r) to
> if (!__builtin_expect(r, 0)) - because of the loop, mutexvar@GOTOFF(%ebx)
> will be hoisted out of the loop, cnt register cleared,

Unconditionally?  That should of course be fixed, although gcc could
discover that cnt doesn't need to be used in the fast path.

> plus last time
> I checked xchgl is more expensive than movl.

Ok, but this is necessary for correctness of the spinlock, no? (I just
took the code from LinuxThreads and modifications from AJ, IIRC) So,
actually we are taking a single movl->xchgl performance hit here.
That by itself would not worry me too much because the threaded case
benefits so immensely.

OTOH, if you have the perfect spinlock macro for both cases, please
just point me to it.

Regards,
Wolfram.


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