Re: Blocking queue race condition?
- From: Johann Klammer <klammerr@xxxxxxxxxxxxx>
- Date: Thu, 05 Jan 2012 22:22:13 +0100
Andrew Tomazos wrote:
Hey all,I tested the code a bit and it seems that it works alright
I'm trying to implement a high performance blocking queue backed by a
circular buffer on top of pthreads, semaphore.h and gcc atomic
builtins. The queue needs to handle multiple simulataneous readers
and writers from different threads.
I've isolated some sort of race condition, and I'm not sure if it's a
faulty assumption about the behavior of some of the atomic operations
and semaphores, or whether my design is fundamentally flawed.
I've extracted and simplified it to the below standalone example. I
would expect that this program never returns. It does however return
after a few hundred thousand iterations with corruption detected in
the queue.
In the below example (for exposition) it doesn't actually store
anything, it just sets to 1 a cell that would hold the actual data,
and 0 to represent an empty cell. There is a counting semaphore
(vacancies) representing the number of vacant cells, and another
counting semaphore (occupants) representing the number of occupied
cells.
Writers do the following:
(1) decrement vacancies
(2) atomically get next head position
(3) write to it
(4) increment occupants
Readers do the opposite:
(1) decrement occupants
(2) atomically get next tail position
(3) read from it
(4) increment vacancies
I would expect that given the above, precisely one thread can be
reading or writing any given cell at one time.
Any ideas about why it doesn't work or debugging strategies
appreciated. Code and output below...
if NUM_TREADS is one. So the race is probably between
several readers or several writers.
it also works if you use a mutex like this(in both take _and_ put):
pthread_mutex_lock(&q_mx);
tmp=tail++;
get( tmp %QUEUE_CAPACITY);
pthread_mutex_unlock(&q_mx);
but _not_ like this(which is equivalent to the atomic ops code):
pthread_mutex_lock(&q_mx);
tmp=tail++;
pthread_mutex_unlock(&q_mx);
get( tmp %QUEUE_CAPACITY);
try to run inside gdb
use 'break file.cpp:<lineno>'
to set a breakpoint at the corruption
'info threads' lists your threads
'tread n' switches between them
'backtrace' shows where you are
help gives help
'p <expr>' prints _any_ expression (even with side effects)
Good Luck
JK
.
- References:
- Blocking queue race condition?
- From: Andrew Tomazos
- Blocking queue race condition?
- Prev by Date: Re: Blocking queue race condition?
- Next by Date: kde dolphin's brain-dead file-sorting!
- Previous by thread: Re: Blocking queue race condition?
- Next by thread: kde dolphin's brain-dead file-sorting!
- Index(es):
Relevant Pages
|
