#75 TMultiWriteSingleReadLockFreeQueue: a late SetEvent from an earlier round can let the reader in while a writer still fills its slot

[Thomas Mueller]

In u_dzMultiWriteSingleReadLockFreeQueue, Enqueue ends with

if InterlockedDecrement(FActiveWriters) = 0 then
  FActiveWritersZeroEvent.SetEvent;

and Dequeue, after swapping the queues, does

FActiveWritersZeroEvent.ResetEvent;
if FActiveWriters <> 0 then
  FActiveWritersZeroEvent.WaitFor(INFINITE);

and then reads the old write queue without checking FActiveWriters again.

Sequence:

1. Writer A decrements FActiveWriters to 0 and is pre-empted before its SetEvent.
2. Writer B increments FActiveWriters to 1, takes the current write queue and reserves a slot with InterlockedIncrement(FWriteIdx), but has not stored its item yet.
3. The reader swaps the queues, calls ResetEvent, sees FActiveWriters = 1 and waits.
4. Writer A resumes and calls SetEvent. That belongs to an earlier round, but it wakes the reader.
5. The reader reads up to FWriteIdx, which already includes B's slot, while B has not written it.

Since the internal queues are reused (Reset does not clear FItems), the reader then gets whatever pointer that slot held in an earlier round, i.e. an item it already handed out and the caller may have freed. B's own item is lost, or ends up in a queue that has been reset.

Expected: after WaitFor returns, the reader re-checks FActiveWriters and waits again (with ResetEvent before the check) until it really is 0.

Found by reading the code during a code review, not reproduced: the window is a few instructions wide.

[Thomas Mueller]

Fixed in revision [r2497].