Does not safely destroy the mutex (pthread_mutex_destroy can get called while in pthread_cond_wait) about wqueue HOT 4 CLOSED

The wqueue destructor should not be called from any of your threads. If any of your threads are trying to do this it is a mistake in your code.

If you look at my examples, in particular the one in Multithreaded Work Queue Based Server in C++, you'll see that the wqueue is created in the main() function and a reference is passed to each of the threads, none of which destroy the wqueue. The wqueue is destroyed only when the program terminates.

If you want to post your code, I'm happy to take a look at it.

from wqueue.

I've looked into your example.

My setting is similiar to yours. I have a producer thread - which is the UI thread of a MFC application that creates and starts the worker thread assigned to one queue. I use your thread and queue implementation.

The worker threads are pointers and the queue is created on stack. Just like your example.

I use the queue to support an autosuggest text box. Each keystroke triggers a query in form of a work item. So, I only need the thread and queue in a single dialog. The constructor of the dialog starts the threads and the deconstructor deletes the thread pointer. The queue (heap variable) is destroyed also after the deconstructor.

I create and destroy the threading mechanism each time the dialog is opened and closed. That's the difference to your code. In fact, I don't see that you deleting the pointers to the worker threads (of type ConnectionHandler in your example). I guess you don't care since the program terminates at that point. However, I have to delete those resources properly.

So, the producer thread should destroy the work queue?

When the work queue is destroyed very rapidly after construction, I get crashes. The stacktrace then shows that the deconstructor of the work queue was called while code inside pthread_cond_wait is being executed. So, the deconstructor of the work queue should wait with destroying the mutex and cond field until the mutex isn't locked anymore. Additionally, the methods of the queue class should not use those resources anymore when they got destroyed.

from wqueue.

The fact that you see the pthread_cond_wait in your stack trace means that you have one or more threads calling wqueue::remove() when the queue is empty, so they are waiting to receive work from the producer thread.

Your producer-consumer usage is different than the example I provided. In my example, the application is a server so, the producer and consumer threads live as long as the server is running. In your case the producer and consumer threads are short lived, so I would suggest the producer send a work item to each worker thread that tells it to quit and not go back to get more work items. The producer thread would then wait until the queue is empty, then delete each worker thread object (which means the producer would have to keep track of your thread object pointers so it could call delete() on each one of them). When all worker threads are destroyed and the queue is empty, then and only then, you are able to safely delete the wqueue object and finally exit the producer thread, which itself must be destroyed somehow by the code that created it.

BTW, my multithread server example does delete work items. It is done in line 69 of server.cpp which in turn deletes the TCPStream objects so the connections are closed. The worker threads are not deleted because the example is a multithreaded server, so the worker threads are supposed to hang around to handle more work when new connections arrive.

I'm going to close this this issue.

from wqueue.

Your first paragraph of your last comment helped me to to find the cause.

Your recommendation how to implement deleting the resources is good, but I rather chose that way:

Now, I add a work item to the queue the worker thread recognizes as signal to break the for-loop and to delete itself. When that work item is being executed it also deletes a pointer to the work queue. Not the most elegant solution, but it works to delete the pointers in the right moment. (e.g. it works only correct if one thread is assigned to the queue)

I never said you don't delete work items.

By the way, you could mention in your docs, that your queue implementation is similiar to Android API's Handler (if only one worker thread powers the queue). I use it as that. My work items all derive from a pure virtual class called Runnable with the single method run(). Similiar to JAVA's Runnable

from wqueue.