Deque Container with an instant consumer for high speed object dumping

Question

I currently have a container that has two features it allows adding objects to it and at the same time an independent thread continuously consumes items from it. It is a FIFO type deque. Which receives object at an extremely high rate. Following is the code for the container

std::deque<Some_object*> my_container;
void Container::Add_item(Some_object* obj)
 {
 try
 {
 {//Begin Lock
 boost::lock_guard<boost::mutex> lock(mutex_lk);
 my_container.push_back(obj);
 }
 condition_consumer_silo.notify_one(); 
 }
 catch (std::exception& e)
 {
 __debugbreak();
 }
 }
 //This method continuously consumes object in FIFO order
 void Container::Consume_Object()
 {
 while(true)
 {
 Some_object* obj; 
 {//Lock
 try
 {
 boost::unique_lock<boost::mutex> lock(mutex_lk);
 while(my_container.empty()) { condition_consumer_silo.wait(lock); }//Block if empty - for spurious wakeup
 if(!my_container.empty())
 {
 obj = my_container.front();
 my_container.pop_front();
 }
 }
 catch (std::exception& e)
 {
 __debugbreak();
 }
 }//Unlock 
 try
 {
 Consume_obj(obj);
 } catch (std::exception& e)
 {
 __debugbreak();
 }
 }//end while
 }

Could this container be improved ? Is there a library out there that would do a better job.

• user90823: hi, got your comment message, hope you get a good answer cheers
• Tobias Hermann: In case you don't get an answer: I'm not quite sure, but I think there is something in "C++ Concurrency in Action" by Anthony Williams that could help you.

Answer 1

Ownership symantics:

void Container::Add_item(Some_object* obj)

Who owns obj? This is a C-Style interface. Don't do it.

It would be better to pass in as unique_ptr. This shows transfer of ownership. Also with good compiler optimization is no more expensive than a normal pointer. This also results in slight modification in your code to make sure it handles ownership correctly.

Note: I would still use: std::deque<Some_object*> my_container;

Lockless queues

Lock are very expensive (relatively to queue management). There is a concept of thread safe lock-less queues.

If you have a very high frequency modification to the queue then that is something I would look into. see How do I build a lockless queue?