Thread never gets the lock (pthread_mutex_lock) - c

Question

Story
According to the man page https://linux.die.net/man/3/pthread_mutex_lock
The mutex object referenced by mutex shall be locked by calling pthread_mutex_lock(). If the mutex is already locked, the calling thread shall block until the mutex becomes available.
I have a program with a thread. Here is the program flow:
The main process and the thread always call pthread_mutex_lock inside of a loop.
When the main process is holding the lock, the thread which is asking for lock, blocks (waiting for lock to be granted).
When the main process releases the lock with pthread_mutex_unlock, the thread should suddenly get the lock.
When the main process asks for the lock again, the main process should wait for the thread to release the lock.
The problem is that, at point 3, the thread does not suddenly get the lock as soon as the main process releases the lock. The main process gets it first when it calls to pthread_mutex_lock in the next loop cycle (at point 4).
How to deal with this situation?
Question
How can I make the thread get the lock as soon as the main process releases the lock?
Simple code to reproduce the problem
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
pthread_mutex_t my_mutex = PTHREAD_MUTEX_INITIALIZER;
void *
my_thread(void *p)
{
(void)p;
while (1) {
pthread_mutex_lock(&my_mutex);
printf("The thread is holding the lock...\n");
sleep(1);
pthread_mutex_unlock(&my_mutex);
}
}
int
main()
{
pthread_t t;
pthread_create(&t, NULL, my_thread, NULL);
pthread_detach(t);
while (1) {
pthread_mutex_lock(&my_mutex);
printf("The main process is holding the lock...\n");
sleep(1);
pthread_mutex_unlock(&my_mutex);
}
}
Compile and Run
gcc test.c -o test -lpthread
./test
Expected result
The main process is holding the lock...
The thread is holding the lock...
The main process is holding the lock...
The thread is holding the lock...
The main process is holding the lock...
The thread is holding the lock...
The main process is holding the lock...
...
Actual result
The main process is holding the lock...
The main process is holding the lock...
The main process is holding the lock...
The main process is holding the lock...
The main process is holding the lock...
The main process is holding the lock...
The main process is holding the lock...
...
Calls story in order
main -> [1] call lock (get the lock)
thread -> [2] call lock (waiting for main to unlock)
main -> [3] call unlock
thread -> [4] (still does not get the lock from [2], why? even though it has been unlocked?)
main -> [5] lock (get the lock again)
thread -> [6] (still does not get the lock from [2])
main -> [7] call unlock
thread -> [8] (still does not get the lock from [2], why? even though it has been unlocked?)
main -> [9] lock (get the lock again)
... and so on ...
Summary
pthread_mutex_lock does not guarantee the order of lock requests.

Answer 1

pthread_mutex_lock guarantees that it will lock until the mutex becomes available. That does not mean that each lock() call enters a queue and is guaranteed to get the mutex lock next. It only means that nobody else will have the lock at the same time.
If you require a certain order, an option would be to use condition variables. That way, you can have a flag that is set to the next member which should get the mutex. You can then wait for the mutex until the value is as expected. See https://linux.die.net/man/3/pthread_cond_wait.
Alternatively, if your example has sleeps in it anyway as above, you can just move the sleep after the unlock() call. While that is not strictly speaking a guarantee, it will most definitely do the trick for a simple test. I do not recommend this approach for anything more serious/complex though.
EDIT: As Shawn correctly added, you can also use pthread_yield (1) to allow another thread to acquire the mutex if you don't care which other thread it is. Some intricacies with yielding are described in sched_yield(2).
PS: I would comment, but my rep is now high enough yet :)

Answer 2

Here is a 'fairlock' as an example; you can do better:
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
typedef struct fairlock FairLock;
struct fairlock {
pthread_mutex_t lock;
pthread_cond_t cv;
long scount;
long wcount;
};
#define err(x,v) do { int t; if ((t=(x)) != (v)) { \
error(__FILE__,__LINE__, #x, t, (v)); \
}} while (0)
static void error(char *fn, int lno, char *s, long x, long v) {
fprintf(stderr, "%s:%d %s returned %ld rather than %ld\n",
fn, lno, s, x, v);
exit(1);
}
void Lock(FairLock *f) {
err(pthread_mutex_lock(&f->lock), 0);
long me = f->scount++;
while (f->wcount != me) {
err(pthread_cond_wait(&f->cv, &f->lock), 0);
}
err(pthread_mutex_unlock(&f->lock), 0);
}
void UnLock(FairLock *f) {
err(pthread_mutex_lock(&f->lock), 0);
if (f->scount > f->wcount) {
f->wcount++;
err(pthread_cond_broadcast(&f->cv), 0);
}
err(pthread_mutex_unlock(&f->lock), 0);
}
FairLock *NewLock(void) {
FairLock *p = malloc(sizeof *p);
if (p != 0) {
err(pthread_mutex_init(&p->lock, 0),0);
err(pthread_cond_init(&p->cv, 0),0);
p->scount = p->wcount = 0;
}
return p;
}
void DoneLock(FairLock *f) {
err(pthread_mutex_destroy(&f->lock), 0);
err(pthread_cond_destroy(&f->cv), 0);
}
And your testlock.c changed to utilize it; again there is room for improvement, but you should be able to stick sleeps just about anywhere and it will remain fair....
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
#include "fairlock.c"
FairLock *my;
void *
my_thread(void *p)
{
while (1) {
Lock(my);
printf("%s is holding the lock...\n", p);
UnLock(my);
}
}
int
main()
{
pthread_t t;
my = NewLock();
pthread_create(&t, NULL, my_thread, "one");
pthread_detach(t);
pthread_create(&t, NULL, my_thread, "two");
pthread_detach(t);
pthread_create(&t, NULL, my_thread, "three");
pthread_detach(t);
pthread_create(&t, NULL, my_thread, "four");
pthread_detach(t);
pthread_create(&t, NULL, my_thread, "five");
pthread_detach(t);
while (1) {
Lock(my);
printf("main process is holding the lock...\n");
UnLock(my);
}
}

Answer 3

TLDR Version:
The very next thing that either of your two loops does after releasing the lock is to try to acquire it again.
When there's a race between thread A which has just released a lock and thread B which has been blocked, waiting for the lock, thread A almost always will win because thread A already is running, and thread B still is "asleep."
Releasing the lock doesn't instantaneously "wake up" the waiting thread. All it does is change the status of the other thread from "waiting for the lock" to "waiting to be assigned a CPU to run on." Some time real soon after, the Scheduler will get around to restoring the context of thread B on another CPU, and thread B will start running, but by then it will be too late. Thread A will have already re-locked the lock.