Re: malloc() and spinlocks

[Wolfram Gloger <Wolfram dot Gloger at dent dot med dot uni-muenchen dot de>]

> Wolfram Gloger wrote:
> 
> > Are you sure?  The patch doesn't contain pure spinlocks;
> > __sched_yield() is called after N lock attempts. 
> 
> sched_yield() isn't guaranteed to do anything.  Several projects used
> sched_yield() over time and all of them broke sooner or later.  jakub,
> what's the OO.org story?

Indeed, what story is that?

> Anyway, assume all spinlocks are taken by low-priority threads.  In
> comes a high-priority thread.  It is runnable.  Therefore sched_yield()
> will find that it always has the right to the CPU.  The only thing you
> could do is use nanosleep() instead of sched_yield() but this could and
> would create horrible delays and again would require adjusting the code
> to the kernel since below a system-dependent delay the waiting is
> active, i.e., the system call is delayed in the kernel and the thread is
> not put to sleep.

Yep, sched_yield() alone doesn't protect against priority-induced
problems.  However, please note that the locking function in the patch
already includes such nanosleep() calls.  The "horrible delays" are
indeed unavoidable AFAICS.  Fortunately, they would happen only in
this _very_ rare case (all malloc locks taken by low-priority
threads).

Basically, the inline locking functions in the patch are taken
verbatim from LinuxThreads (where they are partially out-of-line,
however).  So, if they have priority inversion problems, the
LinuxThreads code (which includes such a spinlock in every mutex
AFAIR) also has them.

I would have preferred to just use fast inline functions from
LinuxThreads directly, but AFAICS they aren't available.

> All this is not a problem with futexes.

Sure, futexes are the way to go for Linux-2.5 and NPTL, no question.
They solve all this correctly.

However, we are going to be stuck with LinuxThreads and 2.4 kernels
for some time to come, so I'm sure a big performance improvement would
be noticed favourably.

Regards,
Wolfram.