No. In the dlq_writer code the only thing I can see that could take any significant time is lock.lock(). I would suggest running the system into a state where throughput has significantly dropped and then getting a thread dump. It may then become apparent what the threads are waiting for.
Generally mutex operations are fast, but there are circumstances where lock contention can slow a system to a crawl.