I spent some time trying to figure out why the lock-free read/write implementation is correct under x86, assuming a multiprocessor environment.<p>My read of the situation was that there's already potential for a double-read / double-write between when the spinlock returns and when the head/tail index is updated.<p>Turns out that I was missing something: there's only one producer thread, and only one consumer thread. If there were multiple of either, then this code would be more fundamentally broken.<p>That said: IMO the use of `new` in modern C++ (as is the case in the writer queue) is often a code smell, especially when std::make_unique would work just as well. Using a unique_ptr would obviate the first concern [0] about the copy constructor not being deleted.<p>(If we used unique_ptr consistently here, we might fix the scary platform-dependent leak in exchange for a likely segfault following a nullptr dereference.)<p>One other comment: the explanation in [1] is slightly incorrect:<p>> we receive back Result* pointers from the results queue rq, then wrap them in a std::unique_ptr and jam them into a vector.<p>We actually receive unique_ptrs from the results queue, then because, um, reasons (probably that we forgot that we made this a unique_ptr), we're wrapping them in another unique_ptr, which works because we're passing a temporary (well, prvalue in C++17) to unique_ptr's constructor -- while that looks like it might invoke the deleted copy-constructor, it's actually an instance of guaranteed copy elision. Also a bit weird to see, but not an issue of correctness.<p>[0] <a href="https://github.com/stong/how-to-exploit-a-double-free#0-internal-data-structures" rel="nofollow">https://github.com/stong/how-to-exploit-a-double-free#0-inte...</a><p>[1] <a href="https://github.com/stong/how-to-exploit-a-double-free#2-receive-results" rel="nofollow">https://github.com/stong/how-to-exploit-a-double-free#2-rece...</a>