Why is another thread, say B running when pthread_mutex is being locked and unlocked inside thread A?

Question

According to the man pages

pthread_mutex_lock locks the given mutex. If the mutex is currently unlocked, it becomes locked and owned by the calling thread, and pthread_mutex_lock returns immediately. If the mutex is already locked by another thread, pthread_mutex_lock suspends the calling thread until the mutex is unlocked.

What I understood is when line 3 executes the main thread has ownership of the mtx . It then performs its critcal region actions and then reaches line 4 and unlocks mtx . My question is -

1. Can the other thread concurrently run when mtx is locked?
2. What is the use of line 2 since newThread can only unlock mtx when line 4 has been executed, and thus makes line 2 redundant?

3. What would happen if line 1 is uncommented?

    #include<stdio.h> #include<pthread.h> #include<semaphore.h> #include<unistd.h> sem_t bin_sem; pthread_mutex_t mtx; char message[100]; void * thread_function(void * arg) { int x; char message2[10]; while(1) { // pthread_mutex_lock(&mtx); //line 1 printf("thread2 : waiting..\\n\\n"); sem_wait(&bin_sem); printf("hi i am the new thread waiting inside critical..\\n"); scanf("%s",message); printf("You entered in newthread:%s\\n\\n",message); sem_post(&bin_sem); pthread_mutex_unlock(&mtx); //line 2 } } int main(void) { pthread_t athread; pthread_attr_t ta; char message2[10]; int x; sem_init(&bin_sem,0,1); pthread_mutex_init(&mtx,NULL); pthread_attr_init(&ta); pthread_attr_setschedpolicy(&ta,SCHED_RR); pthread_create(&athread,&ta,thread_function,NULL); while(1) { pthread_mutex_lock(&mtx); //line 3 printf("main waiting..\\n\\n"); sem_wait(&bin_sem); printf("hi i am the main thread waiting inside critical..\\n"); scanf("%s",message); printf("You entered in main:%s\\n\\n",message); sem_post(&bin_sem); pthread_mutex_unlock(&mtx); //line 4 } sleep(5); } 

Answer 1

A mutex is a mechanism for implementing critical sections.

Any code between pthread_mutex_lock(x) and pthread_mutex_unlock(x) calls will execute in only one thread at any given time. That's all.

So ...

1. Can the other thread concurrently run when mtx is locked?

If it didn't lock the mtx, then of course.

2. What is the use of line 2 since newThread can only unlock mtx when line 4 has been executed, and thus makes line 2 redundant?

The mutex becomes useless, and you also get UB since you're unlocking it in the thread that didn't lock it:

If the mutex type is PTHREAD_MUTEX_DEFAULT ...
Attempting to unlock the mutex if it was not locked by the calling thread results in undefined behavior.

(By default you get mutex type PTHREAD_MUTEX_DEFAULT )

3. What would happen if line 1 is uncommented?

You get thread starvation , since the mutex is locked almost all the time and is immediately re-locked after unlocking (POSIX doesn't guarantee mutex fairness).

A POSIX semaphore does provide fairness in some cases (when you use SCHED_FIFO or SCHED_RR schedulers), but is heavier .

I don't quite understand what you're trying to achieve (the application looks contrived). In a real application there's probably some logical ordering to the actions that either thread needs to take. So if the semaphore works for you, I'd keep it at that and remove the mutex.