I was referring more to the whole series, not just queues being added more than once. Sorry if that wasn't clear. The main issue is it really needs a threaded solution. For example, the ops mutex will naturally become available for locking when the worker thread sleeps on a condition variable, so workarounds become unnecessary; e.g. `is_flushing` disappears. The current implementation is little more than a hack to avoid threading, and the issue with sequencing vkQueuePresentKHR() is the only reason it was done that way.
I am not sure I agree that the current implementation is a hack. It's a solution in which the queue is flushed by whatever thread happens to find it in a flushable state, rather than by a another dedicated thread. To me it feels a completely reasonable choice. At any rate, I am getting convinced too that one or more dedicate threads could be better, though for other reasons. And even in that case I think it's better to avoid holding the lock while processing the queue, so that any thread willing to push something to the queue shouldn't uselessly wait for the queue to be flushed before continuing. So I'd say that this MR is actually a change in the direction of having a dedicated thread, even though that cannot happen until DXGI doesn't need anymore to access the Vulkan queue (I'm working on that too).
Are these changes required to solve the main issue with Present sequencing? If not then I think the Present problem should be fixed on its own, then a threaded ops queue introduced after that.
No, it's not immediately conducive to solving the problem with DXGI. But it still fixes a bug (accessing mutable fields without holding the lock) and should be considered anyway (and, as I said, it will make switching to a threaded CS worker easier as soon as we can).