Boost logo

Boost :

From: Maciej Sobczak (maciej_at_[hidden])
Date: 2003-06-08 06:15:03


William E. Kempf wrote:

> I haven't seen your code to say for sure, but from the limited description
> I believe there's a very high probability that this is the case.

Hm...
I'm ready to accept the argument that having two separate
synchronization primitives to do logically one task can be error-prone
in non-trivial schemes. However, from what I understand, Stefan uses his
semas in roughly this way:

// get single element from queue
1a. semaphore_acquire
2a. mutex_lock
3a. get_elem_from_queue (some equivalent of front+pop_front)
4a. mutex_unlock

// put single element into queue
1b. mutex_lock
2b. put_elem_to_queue (some equivalent of push_back)
3b. mutex_unlock
4b. semaphore_release

I understand that there is a period of time when the program is running
(and therefore is subject to preemption) between 1a and 2a, and that
similar period of time happens between 3b and 4b.

But I do not see the problem -- in typical usage these two pseudocode
sequences are *the only* places in the application where the queue is
accessed. That means that the only effect of race condition (resulting
from preemption between 1a and 2a or between 3b and 4b) is that at some
times the queue will actually have more elements than the sema's counter
value.
It is *not* a danger in the sense that there is no possibility to pop
from the empty queue (once you get green light in 1a, you are sure that
3a will succeed, you just do not care how many elements there are, there
is at least one for sure).

I think that the argument about race conditions is valid when there are
other places in code where the queue is accessed in some way and I
understand that two separate synchronization objects make it more
probable to write flawed code. However, in this simple example, either:
- the race condition does not matter, or
- I miss something obvious

On the other hand (and being frank, it has to be stated loudly), the
above pseudocode does not show that semas should be preferred over
condvars...
I write it for the sake of argument and better understanding of the
rationale.

-- 
Maciej Sobczak
http://www.maciejsobczak.com/
Distributed programming lib for C, C++, Python & Tcl:
http://www.maciejsobczak.com/prog/yami/

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk