[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uclinux-dev
Subject:    Re: [uClinux-dev] patch for semaphore of pthread lib
From:       Falk Brettschneider <falk.brettschneider () gmx ! de>
Date:       2006-10-26 23:21:59
Message-ID: 45414317.5070600 () gmx ! de
[Download RAW message or body]

Hi,

Mike Frysinger schrieb:
>
>
> semaphores are atomic
For the implementation of the semaphore, LinuxThreads for 2.4 kernel
uses that helper mutex __sem_lock additionally to suspend() etc.. NPTL
of 2.6 kernel uses a futex only. Means, since a program can be blocked
in e.g. sem_wait() on __sem_lock before reaching suspend(), we don't
have an atomic semaphore on a 2.4-based uclinux. Thus priority inversion
can hit us there, which means sem_wait()/sem_post() don't work reliable
with multithreaded SCHED_RR programs. This is what I've experienced.
There's no need for a change if one uses SCHED_OTHER, only.
>  ... regardless, you dont do IRQ handling in userspace, 
> end of story
>   
Yes, you're right. It's no good, especially on SMP systems. But I don't
see any other chance to make the semaphore functions really atomic
without rewriting the whole semaphore.c of LinuxThreads.
Afaik RTLinux uses priority inheritance for internal mutexes in
rt_sem_wait() etc. This is also a solution to prevent priority
inversion. So they give a chance to use SCHED_RR apps in a reliable way.
> -mike
>   
Cheers, F@lk

It seems, the problem just can be solved by using another pthread lib
than good old LinuxThreads, after either stepping to kernel 2.6 or by
using those realtime patches. Stopping here.
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
[prev in list] [next in list] [prev in thread] [next in thread]