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?
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk