Re: [boost] Re: no semaphores in boost::thread

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/