如何在C ++ 11中防止线程饥饿 [英] How to prevent threads from starvation in C++11
问题描述
我只是想知道C ++ 11中是否有任何锁定策略可以防止线程饥饿.
我有一堆线程正在争用一个互斥锁.现在，我的问题是，离开关键部分的线程立即开始争夺同一个互斥对象，并且大多数时候都是赢家.因此，等待互斥量的其他线程正在挨饿.
我不想让线程离开临界区，只睡最短的时间，让其他线程有机会锁定互斥锁.
我认为必须有一些参数可以公平锁定等待互斥锁的线程，但是我找不到任何合适的解决方案.
好吧，我发现了std :: this_thread :: yield()函数，该函数旨在重新安排线程的执行顺序，但这仅是对调度程序线程的提示，并且取决于是否重新调度线程. /p>
有什么方法可以为在C ++ 11中等待相同互斥锁的线程提供公平的锁定策略吗? 常用的策略是什么?
谢谢
这是互斥锁中的常见优化，旨在避免在同一线程再次使用互斥锁时浪费时间切换任务.如果当前线程在其时间片中还剩下时间，则通过让它使用互斥锁而不是挂起它，并切换到另一个线程(这可能会导致大量重新加载缓存行以及其他各种延迟).
如果您对互斥量有太多争执，这是一个问题，那么您的应用程序设计是错误的.您将所有这些线程都阻塞在互斥锁上，因此什么也不做:如果没有那么多线程，您可能会更好.
您应该设计您的应用程序，以便如果多个线程争用一个互斥锁，那么哪个线程获取锁并不重要.直接争用也应该是一件罕见的事情，尤其是在有很多线程的情况下直接争用.
我认为这是可以解决的唯一情况是每个线程都在等待条件变量，然后广播该条件变量以唤醒它们.然后，每个线程都将争用该互斥锁，但是如果您这样做正确，那么他们都应该快速检查一下这不是虚假的唤醒，然后释放该互斥锁.即使那样，这也被称为打雷群"情况，这也不是理想的，恰恰是因为它序列化了所有这些线程.
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
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.
这篇关于如何在C ++ 11中防止线程饥饿的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
