Re: to const or not to const
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. 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();
}
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:
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. In that sense, it
changes the logical state of the queue from [unknown] to [known to be non-
empty].
(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.)
Best
Kai-Uwe Bux