CODEWITHSUNDEEP
c++pthreadsmutex
Celeritas
Celeritas

Reputation: 15043

Giving lock to certain thread

Is there a way to give a certain thread priority if multiple threads try to aquire the same mutex at one time

For example you have 2 threads both started at the same time and they sleep then try to acquire lock

In main thread

pthread_mutex_t mut = PTHREAD_MUTEX_INITIALIZER;
pthread_t thrd1, thrd2;
pthread_create( &thrd1, NULL, someFunc, NULL);
pthread_create( &thrd2, NULL, someFunc, NULL);

and someFunc() would have

usleep(1000);
pthread_mutex_lock(&mut);

I thought this had to do with threading priority but that appears to be a different topic. Is there a way to guarantee thread 2 got the lock on mut first?

Upvotes: 0

Views: 319

Answers (1)

jxh
jxh

Reputation: 70402

Your problem is underspecified, because you do not provide any parameters on use case or how you have determined a choice is to be made. You seem to believe that priority alone will be sufficient to get you the behavior you want, but that is a fallacy.

Priority alone is insufficient.

Priority alone does not let a higher priority thread wrest control of a mutex away from a lower priority thread that has acquired a lock. The lower priority thread must voluntarily yield the lock for the sake of safely handling the protected critical section. If the higher priority thread was allowed to yank the mutex away from the lower priority thread, the state in the critical section may be left inconsistent by the lower priority thread, and this could cause problems for the higher priority thread.

Here are some options.

Option 1: Start thread 2 first.

This is the simplest solution. Just launch thread 2 first, and let it notify the main thread when it has acquired the lock. Then, the main thread can start thread 1.

If you really just want each thread to figure it out without intervention from the main thread, then you have the specify what you mean by "guarantee thread 2 got the lock first". If thread 1 truly wakes up first, and goes for the lock without any contention, what do you expect it to do about that? And, how does thread 1 know that it is thread 1 and not thread 2?

Option 2: Why care about which thread is which?

If there is no specific reason that thread 2 is thread 2, then you could just let which ever thread gets the lock first do whatever it is that thread 2 is supposed to do, and the subsequent thread does whatever thread 1 is supposed to do.

This reduces the problem to only needing to know if any thread has gone yet or not. However, if you really do care that thread 2 is supposed to go first, then you still need to handle the case that thread 1 gets the lock out of turn. So, it needs to somehow know that it is thread 1, and it needs to know somehow that thread 2 has not done its thing yet.

Option 3: Make thread 1 wait for thread 2 (somehow).

When the thread starts, it first determines which thread it is. If it is thread 1, it waits for an indication from thread 2 that it can acquire the lock. If it is thread 2, it first acquires the lock, then delivers an indication to thread 1 that it may acquire the lock.

Options 1 and 3 have one thread notifying another thread. There are many variations on how this notification can be delivered. You could use a semaphore, or a condition wait, or a pipe, or even a spin lock. There are many other options, it just depends on what you believe is the right choice for your application.

Upvotes: 1

Related Questions