Actually, it converts the asynchronous commands from the threads or forks into a single synchronous stream. This mimicks an early IBM-mainframe style solution to transaction processing from way back.

With all the inherent problems of those early attempts to deal with this problem.

The basic problem with serialising commands from asynchronous threads of executions (TOE), is that they frequently, very rapidly descend into lock-step. This where all the threads bar one end up waiting for the current thread to complete. And when it does, then next gets to do one thing, then the next. And before the queue is played out, the original thread has joined the end and you are into a cycle.

And that cycle consists of each thread doing some trivial amount of processing before blocking on the shared resource and then having to wait several context switches for all the other TOEs to have their chance. The net result is that throughput slows to a crawl.

The modern incarnation of the idea, Software Transactional Memory, avoids some of the problems of the older manifestations by using very optimistic operations. That is, instead of waiting on a lock before going forward with operations, they go ahead on the assumption that it's okay, and then check after to see if it was; and redo the operation if it wasn't.

However, despite the the big guns in concurrency research-- Edinburgh, Brown et al.--having done a huge amount of intensive research on STM in the past few years, I'm unaware of any practical implementations outside of the pure functional languages. And even there, there is good evidence that for generic real-world workloads, thread starvation--individual threads that make no progress--is a frequent problem with no solution. And that well crafted lock-free solutions beat STM for performance, throughput and fairness.