# Deque Container with an instant consumer for high speed object dumping

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;

{
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.

• hi, got your comment message, hope you get a good answer cheers – user90823 Aug 5 '13 at 3:35
• 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. – Tobias Hermann Aug 5 '13 at 14:51

### 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?