Re: to const or not to const
On Apr 9, 10:32 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
James Kanze wrote:
On Apr 9, 4:22 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
I recently dived into multi-threaded issues. To make my
life a little easier, I decided that it would be nice to
have a simple fifo buffer to ease communications between
threads. The interface is this:
template < typename T >
class fifo {
public:
typedef T value_type;
typedef std::size_t size_type
fifo ( size_type n = -1 );
void push ( value_type const & value );
value_type pop ( void );
// blocks until an item is available
bool available ( void ) const;
// returns true if the a call to pop() would not block
void wait_available ( void ); // should this be const ?
// blocks until a call to pop() will not block
};
Typically there are some threads push()ing items into the
fifo and one thread pop()ing items off the buffer and
processing them.
If there's more than one thread popping, available and
wait_available are useless, of course.
Yes.
In my own code, I've handled this by providing a timeout on
pop: if zero, it returns immediately, and if infinity, it
behaves effectively as your pop. But I've also had cases
where it made sense to wait at most 100 milliseconds, or
such. (This solution also avoids the const problem:-).)
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.
It is clear that push() and pop() should not be const: they
change the contents of the buffer. Also, availble() should
be const since it just returns a property of the buffer
without modifying it.
But, what about wait_available()? Even though it does not
change the buffer contents by itself, once it returns it
effectively signals to the thread where it was called that
another thread has pushed in item. So it marks a change of
the buffer, even though it does not in itself bring that
change about. Should this method be const or not?
Does it change the (logical) contents of the buffer or not?
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.)
Practically speaking, however: is there the slightest reason
to worry about const on this class? Are there any real
scenarios where one might pass a const reference to it, or
not have access to the non-const instance for some reason?
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.
--
James Kanze