I have another method which processes items in the queue and then sleeps 3 seconds. The problem (I'm assuming) is that sometines the inotifywait method won't release the lock on the queue.

What is the purpose of the 3 second sleep?

It's much more likely that the problem is that your 3 second sleep is preventing the read thread from processing its end of the queue in a timely manner. You can write a huge amount of data to a queue in 3 seconds.

There should be no reason to have sleeps in the reader end of the queue. If you code it so that it just blocks on the dequeue(), it won't consume any cpu until there is something for it to do, but will be able to respond immediately (subject to getting its next timeslice) as soon as there is something to do.

If you are using dequeue_nb() in order to allow that thread to also check for other conditions, for example a "terminate now" command, and you want to prevent that thread running away with the cpu, then you should use a much shorter sleep. A sleep of <timeslice> milliseconds is theoretically most efficient, but any reasonable value will work well. Generally, start with say 50 milliseconds (usleep 50;) and vary it it up or down to strike a balance between idle thread cpu consumption and responsiveness.

As a safe guard to prevent the writing thread running away with memory, it can relinquish its timeslice if the size of the queue gets bigger than some limit: sleep 0 if $Q->pending > 100;. Again, if that thread is not blocking on pipe read, then using a timeslice-sized sleep instead of zero will prevent the thread running away with the cpu.

It would be easier to make suggestions if you posted the reader thread code also.