This also seems like a good place where something simpler than a spin lock could be useful: a simple queue.

After all, the posting of comments is a single conceptual entity that must remain sequential because of the wait. There is no need to parallelize it because it can't function in parallel and it doesn't involve any processing which would take longer than three real-world seconds.

So instead of having things spin on a mutex, it's conceptually simpler to have the streaming monitor (which does do enough computation to require its own thread) be able to throw comment IDs up on a "blackboard" list from which a relatively straightforward comment poster thread function takes the first, up votes, makes its log entry, waits three seconds, and then does it all over again forever. If the blackboard is empty, do nothing and go straight to the wait.

This as the main advantage of not requiring a thread pool at all with a predefined number of workers. The maximum amount of concurrency this flow can possibly have is two threads in a reasonable sense so there's no real sense in having more than that.

(I'm pretty sure that concurrent has some built-in magic for shared variables probably using a mutex under the hood, but there's no need to reimplement the wheel, really. Then again, I may have been spoiled by years of writing in Erlang for concurrency, where passing information between independent threads is built into the base of the language via a straightforward message passing system.)