[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 8:40:38
Message-ID: 20061026084038.20180 () gmx ! net
[Download RAW message or body]

Hi, 
thanks for your reply.

Mike Frysinger <vapier@gentoo.org> wrote:

> On Wednesday 25 October 2006 16:50, Falk Brettschneider wrote:
> > 1) I replaced all occurrences of the internally used helper mutex
> > __sem_lock with local_[dis|en]able_irq() in semaphore.c
> 
> that'll never fly in general ... irq control is the domain of
> kernel space and no where else
one solution to fix thread priority inversion is to make the problematic code atomic. \
The only alternative to a mutex is to use IRQ-disabling to let it be atomic also. \
Well, the pthread lib is not part of the kernel, but in my opinion lowlevel thread \
management actually sounds much like a kernel job. Do you have an idea how semaphores \
can be IRQ-safe?

If one has a complex multithreaded SCHED_RR user program with IRQ handling and much \
usage of semaphores, I think atomic semaphores are absolutely necessary for a working \
synchronization. Can you agree with that? I think reliable program synchronization \
tools are a matter of the operating system.

> 
> > 2) I avoid locking 
> > on the other internal helper mutex (in function
> > __pthread_set_own_extricate_if() in spinlock.h) for all threads which
> > are configured as PTHREAD_CANCEL_DISABLE.
> 
> i dont understand why
That p_lock locked in __pthread_set_own_extricate_if() just guards the access to \
member variable p_extricate. But the only other place where p_extricate is accessed \
is in pthread_cancel and pthread_trycancel. Both functions shouldn't access \
p_extricate if one set the thread to pthread_setcancelstate(PTHREAD_CANCEL_DISABLE). \
So it's OK to not use the mutex for this thread state. My thread (with \
state=PTHREAD_CANCEL_DISABLE) deadlocked there although the p_lock is not necessary.

> and since it is optional, linuxthreads doesnt bother to support it
So if they had used LinuxThreads for the Pathfinder, the would have bad luck. ;)

Cheers, F@lk

-- 
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl
_______________________________________________
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]