Re: [Boost-users] [Thread] What do I #include?

From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2008-07-11 10:56:16

"Khandelwal, Amit" <amit.khandelwal_at_[hidden]> writes:

> 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