Issue with Lock Ordering or Scheduling

问题:

I have a C application that uses pthreads.

There is a lock contention between two threads(say A and B) where A gets the lock first while B is waiting for the lock, Once A is done and releases the lock, B still doesn't get it and after a while A gets the lock again(A does acquire and release in a loop).
If I attach my process to gdb and pause thread A after it has given up the lock and manually continue on thread B, it then gets it and does what is needed.

This does not look like a dead lock to me. What could be preventing thread B from getting the lock? Any help is greatly appreciated.

Sample Code:

Thread A:

while (true)  
{  
    lock.acquire(lock)  
    // Do stuff  
    lock.release(lock)  
    // Do more stuff  
}  

Thread B:

lock.acquire(lock)  
// Do some stuff  
lock.release(lock)  

回答1:

It looks that you algorithm suffers from starvation, you should queue your access to the lock, see

pthreads: thread starvation caused by quick re-locking

or

Fair critical section (Linux)

As an answer to the comment, what is a mutex (pthread library)

A mutex is a lock (from Pthread library) that guarantees the following three things:

Atomicity - Locking a mutex is an atomic operation, meaning that the threads library assures you that if you lock a mutex, no other thread can succeed in locking that mutex at the same time.

Singularity - If a thread managed to lock a mutex, it is assured that no other thread will be able to lock the same mutex until the original thread releases the lock.

Non-Busy Wait - If threadA attempts to lock a mutex that was locked by threadB, the threadA will get suspended (and will not consume any CPU resources) until the lock is freed by threadB. When threadB unlocks the mutex, then the threadA will wake up and continue execution, having the mutex locked by it.

It do not guaranty fairness.

If you are still interested in sort of reader writer fairness for pthread_rwlock_rdlock: which are allowed to favour writers over readers to avoid writer starvation.

回答2:

Another possibility is that your lock has been claimed earlier on the A thread preventing the lock/release to release fully (lock count thread stays too high).

Starvation is another strong possibility, but your question states "after a while A gets the lock again" indicating more than a few microseconds :), which should prevent starvation.

Is it possible that you return from A or use a continue statement, thus keeping the lock?