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

This is a discussion on priority inversion due to pthread_mutex_lock(): how to avoid? within the C Programming forums, part of the General Programming Boards category; Could you suggest me a quite general way to avoid the priority inversion that may happen in this situation: Thread1 ...

  1. #1
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251

    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?
    Last edited by mynickmynick; 04-07-2009 at 08:55 AM.

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    Quote Originally Posted by matsp View Post
    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

    thank you but "short period of time" does not solve cause in that short time Thread2 can wake up

    Please read the editing i made on the previous post

    Thank you

  4. #4
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    for the moment i guess two solutions:
    (1) avoid to have an intermediate thread (Thread2) between two threads sharing a lock
    (2) changing dynamically thread priority just outside lock/unlock section

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    [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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #6
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    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.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #7
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    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

  8. #8
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    Quote Originally Posted by mynickmynick View Post
    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
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  9. #9
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    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

  10. #10
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    Quote Originally Posted by mynickmynick View Post
    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.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  11. #11
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    Quote Originally Posted by brewbuck View Post
    I think it has something to do with the mutex attributes, you could start there.
    Thank you
    I found this:
    pthread_mutexattr_setprotocol(3) - Linux man page

    I will test on my system if these settings are avilable or not

  12. #12
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    PTHREAD_PRIO_INHERIT is the one

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. crazy pipe/fork
    By fortune2k in forum C Programming
    Replies: 8
    Last Post: 03-13-2009, 11:28 AM
  2. Priority queue
    By cjwenigma in forum C++ Programming
    Replies: 6
    Last Post: 12-03-2007, 12:30 AM
  3. Priority Queue Help
    By cjwenigma in forum C++ Programming
    Replies: 6
    Last Post: 11-14-2007, 11:48 PM
  4. priority list won't work, i give up
    By teamster in forum C Programming
    Replies: 8
    Last Post: 10-19-2006, 12:26 PM
  5. Priority Queue Question
    By ac251404 in forum C++ Programming
    Replies: 26
    Last Post: 08-16-2006, 11:51 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21