[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] Workaround-Patch for priority inversion in pthread lib of kernel 2.6
On Tue, Apr 21, 2009 at 8:34 PM, Brettschneider Falk
> I experienced hangs of PetaLinux (kernel 2.6) because my multi-threaded user app uses SCHED_RR and runs into thread-inversion problems.
> This is a known problem I've already seen in older uClinux releases for the microblaze (with kernel 2.4).
> The actual problem is based in the pthread library itself. Once it was discussed here: http://readlist.com/lists/uclinux.org/uclinux-dev/0/3487.html and the final conclusion was that the problem will be fixed with kernel 2.6 together with the NPTL library instead of the pthread library. Unfortunately, pthreads are still used, that's why the problem is still not solved.
> My attached patch doesn't fully solve the problem, but fixes the thread-inversion for single-CPU-architectures which I suppose most microblaze systems are. That is why I framed the changes with #ifdef CONFIG_SMP.
> Please, can you apply it at least to the PetaLinux distribution?
Unfortunately there's a pretty fundamental problem with this patch -
including asm/system.h, and calling local_irq_disable() in library (==
userspace) code, is, well, evil :-( It also won't work on any CPU
that implements privileged instructions, which includes microblaze
when the MMU is enabled (not that we are using uClibc in that case,
but it's a step in the wrong direction).
Another minor nitpick is that the kernel option CONFIG_SMP is not
supposed to be tested in userspace/library context, only in the
kernel. The fact that it works is just an artifact of how the
original uClinux-dist build environment is held together.
AFAIK the sensible way to solve priority inversion is to implement
priority inheritance - basically when a thread blocks on a resource,
you temporarily escalate the holding thread to the same or higher
priority, until it releases the resource. This allows the holding
thread to complete its use of the resource and free it up so the
higher priority thread gets a turn on the CPU.
I seem to recall looking at this in a pthreads context years ago, and
the implementation didn't look too horrific. No doubt there are corner
cases, but it's got to be cleaner than doing IRQ disabling in
Sorry for such a negative response, but it's just not something we can
reasonably add in its current form.
My hope is that we'll see progress on NPTL for MicroBlaze in the
not-too-distant future - in the meantime this patch will of course be
archived and found by anyone searching for the right keywords.
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
microblaze-uclinux mailing list
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/