Hi, thanks for your reply. Mike Frysinger 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