"Khandelwal, Amit"
Hmm...I don't know why you say that there will be a race condition. Let say 2 threads are calling pop on the queue and another thread is calling front(). Let us call these 3 thread p1, p2 (for pop) and f1 for front.
As per my understanding - this could be one possible scenario.
P1 -- acquire the lock P2 -- blocked on the lock F1 -- blocked on the lock
P1 -- done and waiting on the lock P2 -- still blocking F1 -- acquired the lock
So where is the race condition ?
Two threads retrieving a value: each does some_var=queue.front(); queue.pop(); Though each operation is thread-safe, the combination isn't, because they can interleave badly: T1: some_var=queue.front(); T2: some_var=queue.front(); // oops we just got the same value T1: queue.pop(); T2: queue.pop(); // Oops the second value in the queue just got //discarded without being read This is a race condition: the outcome depends on the ordering of operations in separate threads. There's a similar problem with empty(). Suppose each thread does if(!queue.empty()) { some_var=queue.front(); queue.pop(); } Two threads can interleave again to give a race condition: T1: if(!queue.empty()) // queue is not empty T2: if(!queue.empty()) // queue is not empty T1: some_var=queue.front(); T1: queue.pop(); T2: some_var=queue.front(); // oops reading non-existent element T2: queue.pop(); // oops no element to pop. Designing interfaces for multi-threaded use is not as simple as just slapping a mutex on the data and locking it in every member function. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL