Thread: priority inversion due to pthread_mutex_lock(): how to avoid?

Could you suggest me a quite general way to avoid the priority inversion that may happen in this situation:
Thread1 has priority 1
Thread2 has priority 2
Thread3 has priority 3

Thread1 gets a mutex and enters the critic section
Thread3 stops on the same mutex
Thread2 wakes up so Thread1 is scheduled out for running Thread2
As long as Thread2 runs, Thread3, which has higher priority, is stopped by a lower priority thread for a potentially long time (while Thread1 would have blocked him for the very short time of execution of a critical section)

One way (but i guess pretty time consuming) is to raise up temporarily Thread1 priority to 3 just before getting the mutex (and releasing high priority just after having released the mutex)
This I guess would make me loose much CPU time? Or is it priority change very fast?

There is no "magic bullet" to solve this problem - the simple solution is to not let a lower-priority thread hold a lock for longer than the high priority thread can tolerate. Enforcing this can be VERY hard.

Generally, sharing locks between processes/threads of different priorities doesn't work well... You should probably consider a solution which involves a different way to deal with the "lock" - e.g. use a message passing system where you don't have to lock at all or for a very short period of time.

--
Mats

[I use the term process as a synonym to thread here - I'm just too lazy to write process/thread]

Well, the usual way to deal with priority inversion is to let the OS raise the priority of a process when it's being waited on by a higher priority process.

Using priorities to control which process runs when is a flawed principle in itself (at least in an OS which hasn't got a strict priority scheme, and unless you are using one an embedded version of Linux, it's not going to be the case). If you want to know which process runs when, then YOU need to use YOUR semaphores or locks to block/unblock processes.

But aside from that, my suggestion of using a different mechanism that doesn't block will still work.

--
Mats

pthreads supports a few mutex locking protocols which implement priority inheritance. You shouldn't really have to worry about this too much. If multiple threads wait on a mutex, the thread which holds it will be boosted to the priority of the highest priority waiting thread.

You do have to configure this. See the manual for pthreads.

Originally Posted by mynickmynick

is this available also with LinuxThreads (instead of NPTL)? My colleagues provided me with an Embedded Linux based on buildroot and uclibc (not glibc) that has LinuxThreads

The Google results are not immediately enlightening... This will take some investigation

Originally Posted by mynickmynick

thank you
I am having a look myself but it's taking long cause I don't even know how to set the priority inheritance ON with pthreads

I think it has something to do with the mutex attributes, you could start there.