I think, timeouts address a slightly different problem.
Fundamentally, yes. They can do a lot more than you need. But
timeouts of 0 and infinity effectively support what you seem to
need as well.
Here
is what I use available() for when there is only one consumer:
while ( true ) {
if ( ! fifo.available() ) {
update_screen();
}
event e = fifo.pop();
e.handle();
}
update_screen(); // if necessary before the first event.
while ( true ) {
event e = fifo.pop(infinite_timeout);
while (e.valid()) {
e.handle();
e = fifo.pop(timeout_0);
}
update_screen();
}
I think that basically does the same thing as your loop.
Of course, if you don't already have a queue with timeouts, and
you don't need it, your solution would probably be simpler to
implement, and thus more appropriate. (You don't, for example,
have to provide an invalid event state---although this is
already present if your queue returns an std::auto_ptr.)
(It's interesting to note that while the two versions do the
same thing, they say something different to the reader. Yours
says: if there's nothing to do, update the screen; then wait for
an event. Mine says process all events that have arrived, then
update the screen.)
This loop handles events as long as they are available and
only when there is a slow down on the producer side, the
screen is updated.
Well, you could have something like this in the consumer thread:
What the client code does after the function is irrelevant to
whether the function is "const". A function is const if 1) it
doesn't modify the internal state (or what is considered the
internal state of that object) of the object, and 2) it doesn't
provide a "backdoor", a means by which the client code can
modify the internal state of the object without referring to the
object.
bool b; // only introduced for exposition
while ( b = buffer.available() ) // really = not ==
{
buffer.pop()
}
// now, b is false, i.e., the last call to available() returned false.
buffer.wait_available();
assert( b != buffer.available() ) // available() now returns true.
The point is: even though wait_available() does not alter the
contents of the queue, in the case of a single consumer you
can _know_ that the queue is non-empty immediately after
wait_available() returns.
So, should std::vector<>::size() be non-const, simply because
the client code can know something about the vector after that,
and perhaps call a non-const function on it as a consequence of
that knowledge? By that logic, nothing can be const.
In that sense, it changes the logical state of the queue from
[unknown] to [known to be non- empty].
The logical state of the queue is never unknown to the queue.
And that's all that matters: see above: by your logic,
std::vector<>::size() changes the logical state of the vector
from [size unknown] to [size known to be some specific value].
(C++ objects do not involve quantum mechanics: observing the
state does not "fix" it, where it was undetermined before.)
(Since we agree that wait_available() is useless in the case
of several consumer threads, I only discuss the remaining use
case.)
No, it's not a question of practical relevance. But, through
this example I realized that my intuition about what is
"logical constness" gets shaky when there are multiple threads
involved. (I am slowly getting ready for C++0X, I guess.)
"Logical const-ness" is a tenuous concept when different
entities have different views of an object. State that is
internal, and irrelevant to const, in one view might be exposed
in another.
.)