Question

I have a logger class with a tbb::concurrent_queue as a member field. Threads using a logger object call a method to push a message onto this internal queue. The logger has an internal thread which is consuming these messages until it receives a sentinel message and then this internal thread exits. The thing is, if clients of this logger object try to log more messages into this logger (after the call to shutdown has sent the sentinel) the messages are passed onto the queue but never picked up on the other end and silently lost. Ideally I would like to notify when this is the case but using a flag set by the internal consumer thread upon exit to check each time im about to push a new message onto the queue would add a branch cost to what is a critical path for me.

One idea i heard was that maybe the consumer thread..right before exiting..somehow atomically swap out the pointer of the queue so that the next call to it would call something else which could handle the message differently now..

i.e. the call: m_buffer->push(message) where m_buffer is a pointer to a tbb::concurrent_queue should after the consumer thread is done still look like m_buffer->push(message) except it goes somewhere else..a custom handler of mine or so…

How can I do this though? I cant swap m_buffer to point to any other custom class unless I inherit from tbb::concurrent_queue…is there another way to get around this?

Thanks

Answer 1

Sounds more like a design problem to me. What do clients of a logger want? To log a message. They don’t care whether it goes onto a queue, or is written out to the screen, or is written onto a piece of paper, inserted into a glass bottle and thrown into the ocean.

So your logger need only expose a log() method, nothing else. Queue swapping would happen internally, by keeping two queues in an array and atomically switching a pointer or index around.

Also, if the speed of your logging code is critical, you might be doing too much of it…