Question

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)  

Answer 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.