Re: Threads: Other Primitives

From: dmoore99atwork (dmoore_at_[hidden])
Date: 2002-03-13 21:19:22

--- In boost_at_y..., "danl_miller" <danl_miller_at_b...> wrote:
> > It sounds like the semaphore you are proposing would block
> > readers who call "down" when count == 0 and would block writers
> > who call "up" when count == MAX?
> 
>   No.

On the subject of semaphores modeling a finite resource where only N 
pooled workers are doled out work at a time - I am familiar with this 
model, and on platforms with native semaphore support these provide a 
primitive very much in line with what is being modeled.  In other 
words, I agree, and I'm hopeful that we can revisit safe/cross-
platform usage in Boost.Threads

- snip -

>  Note in this topic
> that the population is not inherently fixed-size [just like the
> Dorito's ads with Jay Leno a decade ago: "They'll make more!"]
> (although for efficiency reasons, the message-queue---the
> stereotypical use of the producer/consumer pattern in real-time
> systems---would impose a fixed size in real-time systems so that
> an upper-bound is established to guarantee availability of
> resources as the real-time embedded software executes without
> restart for months or years or decades).  

I think this is where my question is coming from, and I don't mean to 
be difficult, but -how- do you enforce the upper-bound on the message-
queue size using only a classic "Dijkstra" semaphore?  If the 
production is running ahead of consumption, the warehouse will be 
full of Doritos!!! :-)  It just seems to me that to provide the 
ability for the producer to block when this upper limit is reached, 
then that's more like a condition variable to me.  Semaphores seem a 
natural fit for controlling consumption, but not for capping 
production.  You'd need a reverse-semaphore or something like that...

I get the distinct impression that I'm still missing something here.  
Please help.

Dave