3

When I have three threads or more, if mutex unlock in one thread, which one will be the next to process? They are in FIFO rule? If not FIFO, several thread wait unlock(), will have a thread never process? Do they wait in a sorted queue and what is the rule to sort them?

Sample code:

//thread No.1
func1(){
  std::unique_lock<mutex> lock(_mtx);
  //do something, now in here,and will leave this thread then mutex will unlock
}

//thread No.2
func2(){
  std::unique_lock<mutex> lock(_mtx);
  //do something
}

//thread No.3
func3(){
  std::unique_lock<mutex> lock(_mtx);
  //do something
}
Adrian Mole
  • 49,934
  • 160
  • 51
  • 83
Yacheng Liu
  • 51
  • 4
  • 1
    it is random the OS will choose what to execute unless you define your own scheduling rules. – Anis Belaid Oct 27 '21 at 09:48
  • 1
    The operating system decides which thread to run next. There is no FIFO rule in C++, but I don't know if the operating system will implement it. – VLL Oct 27 '21 at 09:48
  • Does this answer your question? [many locks on same mutex, one locks forever](https://stackoverflow.com/questions/39878090/many-locks-on-same-mutex-one-locks-forever) – Raymond Chen Oct 27 '21 at 10:14
  • Strict FIFO locks lead to a problem known as a "lock convoy". – Raymond Chen Oct 27 '21 at 10:17
  • @Raymond Chen I have seen your recommendation link. But I still confuse about my question. And I think one of their suggestions is useful, like If I meet the problem like starve thread, I will try to use yield in the other thread to increase efficiency. – Yacheng Liu Oct 28 '21 at 10:25

1 Answers1

3

The operating system will decide on which thread getting the mutex is the most efficient. It is your responsibility to ensure that whatever thread gets scheduled does work that you need it to do.

Generally, it's not possible for a thread to be denied the mutex for very long because eventually all the other threads will either block or exhaust their timeslices, allowing that thread to acquire the mutex. But the platform doesn't provide any particular guarantee of fairness.

You wouldn't want FIFO. That would be a complete disaster. Imagine if each thread needed to acquire the lock 100 times. Now one thread gets the lock, releases it, and then tries to get the lock against almost immediately. Do you want it to stop and switch to one of the other threads every time? Do you want 300 context switches and start/stops? You definitely don't.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • Thx. As you mentioned, OS will decide which thread will get the mutex. And I am lack of knowledge about CPU run timeslices, so I can not understand the threads will either block or exhaust timeslices part. Do you have recommend information link let me learn about it? And actually I think FIFO is fit for my demand, in your example, the thread which release the lock always latter than others, so it won't get the mutex before the other process ended. Maybe I misunderstood your point, and please let me know it, thx so much. – Yacheng Liu Oct 28 '21 at 10:31