0

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)
keeda
  • 2,605
  • 5
  • 28
  • 27

2 Answers2

3

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.

Community
  • 1
  • 1
Michael
  • 2,827
  • 4
  • 30
  • 47
  • Does mutext not does that internally using mutex->waiters ? – keeda Feb 06 '13 at 19:45
  • @keeda: It wakes up any waiting threads at unlock, but those woken threads are not necessarily scheduled straight away - for example if you have only a single core, then your original thread will usually be allowed to finish its timeslice before it is preempted. Pthreads mutexes are very lightweight, and are not designed to be "fair". – caf Feb 06 '13 at 21:54
  • Thanks Caf, I figured it out. I am trying to implement a fair FIFO lock using something like a queue that would guarantee fairness. trying to implement [link]http://en.wikipedia.org/wiki/Ticket_lock – keeda Feb 06 '13 at 22:29
0

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?

Kees Spoelstra
  • 299
  • 2
  • 3