12

I am just wondering if there is any locking policy in C++11 which would prevent threads from starvation.

I have a bunch of threads which are competing for one mutex. Now, my problem is that the thread which is leaving a critical section starts immediately compete for the same mutex and most of the time wins. Therefore other threads waiting on the mutex are starving.

I do not want to let the thread, leaving a critical section, sleep for some minimal amount of time to give other threads a chance to lock the mutex.

I thought that there must be some parameter which would enable fair locking for threads waiting on the mutex but I wasn't able to find any appropriate solution.

Well I found std::this_thread::yield() function, which suppose to reschedule the order of threads execution, but it is only hint to scheduler thread and depends on scheduler thread implementation if it reschedule the threads or not.

Is there any way how to provide fair locking policy for the threads waiting on the same mutex in C++11? What are the usual strategies?

Thanks

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524
Tomas Sedlacek
  • 345
  • 4
  • 11
  • 1
    http://stackoverflow.com/questions/11666610/how-to-give-priority-to-privileged-thread-in-mutex-locking Here a link that might help you!! – William Proulx Apr 09 '13 at 20:05
  • This would appear to be a design issue not a thread starvation issue, can you post code to let people see it and perhaps help. – dirvine Apr 09 '13 at 20:54
  • 1
    You should generally not have a bunch of threads competing for one mutex -- if your code is that serial that only one thread can do work at once, why not have fewer threads? There are valid reasons, but they are not all the same valid reasons, and they can have different answers! – Yakk - Adam Nevraumont Apr 12 '13 at 15:15
  • The reason why I have bunch of threads competing for one mutex is that I am trying to implement monitor design pattern to dining philosophers problem. Ie. all methods operating above shared data are synchronized via monitor public methods. Each public method locks the mutex at the beginning, check if it can progress and if not it suspends and wait on a condition variable. – Tomas Sedlacek Apr 14 '13 at 19:12

1 Answers1

8

This is a common optimization in mutexes designed to avoid wasting time switching tasks when the same thread can take the mutex again. If the current thread still has time left in its time slice then you get more throughput in terms of user-instructions-executed-per-second by letting it take the mutex rather than suspending it, and switching to another thread (which likely causes a big reload of cache lines and various other delays).

If you have so much contention on a mutex that this is a problem then your application design is wrong. You have all these threads blocked on a mutex, and therefore not doing anything: you are probably better off without so many threads.

You should design your application so that if multiple threads compete for a mutex then it doesn't matter which thread gets the lock. Direct contention should also be a rare thing, especially direct contention with lots of threads.

The only situation where I can think this is an OK scenario is where every thread is waiting on a condition variable, which is then broadcast to wake them all. Every thread will then contend for the mutex, but if you are doing this right then they should all do a quick check that this isn't a spurious wake and then release the mutex. Even then, this is called a "thundering herd" situation, and is not ideal, precisely because it serializes all these threads.

Anthony Williams
  • 66,628
  • 14
  • 133
  • 155
  • Sometimes design is not yours and admitting the design is bad does not magically make the problem solved. I ended up here because i am trying to address thread starvation in mic offload library. Authors for some reason assumed that it is ok to protect shared resource, even for multiple devices using single mutex. – Jacek Tomaka Mar 08 '23 at 03:07