From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-21 12:22:27
--- In boost_at_[hidden], "Greg Colvin" <gcolvin_at_u...> wrote:
> From: William Kempf <sirwillard_at_m...>>
> --- In boost_at_[hidden], "Greg Colvin" <gcolvin_at_u...> wrote:
> > > From: "William Kempf" <sirwillard_at_m...>
> > > > --- In boost_at_[hidden], "Greg Colvin" <gcolvin_at_u...> wrote:
> > > > > From: "William Kempf" <sirwillard_at_m...>
> > > > > > --- In boost_at_[hidden], "Greg Colvin" <gcolvin_at_u...>
wrote:
> > > Makes perfect sense to me. See the example code below.
> > >
> > > > You've set it up so the only way to notify a condition is by
> > first
> > > > waiting on a second condition. I don't see how this would
even
> > > > work. Who would notify your "in" condition? How would they
> > insure
> > > > at compile time that the mutex was locked? I see nothing
solved
> > here
> > > > and see little purpose in having an "out" condition.
> > >
> > > Typically the conditions start out signaled, so the very
> > > first attempt to wait on them returns immediately.
CVs aren't like Win32 events. They don't "remain signaled". I
realize that our own CVs could behave differently, allowing this to
work the way you describe, but see my point below.
I should also note that your proposal assumes some relationship
between the two CVs. Often there will be no relationship at all. It
seems like you've simply attempted to find a resolution for a single
problem instead of thinking about general useage patterns.
> > > Here is the classic two-condition example, where after waiting
on
> > > nonfull you need to notify nonempty, and after waiting on
nonempty
> > > you need to notify nonfull.
> > >
> > > class buffer : mutex {
> > > int p,c,n;
> > > vector<int> buf;
> > > condition nonfull, nonempty;
> > > public:
> > > buffer(int n) : p(0),c(0),n(0),buf(n){}
> > > void send (int m) {
> > > wait entry(this,(free1 == buf.size())
(n),nonfull,nonempty);
> > > buf[p] = m;
> > > p = (p+1)%buf.size();
> > > ++n;
> > > }
> > > int receive() {
> > > wait entry(this,(free1 == 0)(n),nonempty,nonfull);
> > > int i = buf[c];
> > > c = (c+1)%buf.size();
> > > --n;
> > > return i;
> > > }
> > > };
> >
> > And if we have only one condition? What will you do then, use an
> > artificial second condition just to satisfy the need for two
> > conditions? What if we have three conditions we must wait on?
>
> I previously presented a single condition variation, but
> left it out of this example to keep it simple. Sorry.
So you're proposing seperate CV implementations depending on the
number of conditions used?
> I don't see any difficulty with more than two conditions.
Which "out condition" do you signal? Both?
> > Again, I see no purpose to signal a second condition on exit of
the
> > wait in a general fashion. It may work in some specific cases,
but
> > it's pointless in most.
>
> In a multi-queue setup you will always want to signal a condition
> at the end of each handler. How else to make any progress?
This isn't necessarily true. However, the biggest problem is that
you're addressing the "bounded buffer/producer consumer" problem
specifically, with out thinking about how the CV can be used outside
of this single problem domain.
Bill Kempf