These are used by The Obsessive Shadow. I didn't try to figure out RTL_BARRIER structure layout / usage on Windows, just used the fields needed for what I think is reasonable implementation matching the tests. I'd like to put some notes on DeleteSynchronizationBarrier() logic (as it seems to me the name and the description in MS Docs is a bit misleading). As stated in [1], "To release a synchronization barrier when it is no longer needed, call DeleteSynchronizationBarrier. It is safe to call this function immediately after calling EnterSynchronizationBarrier because that function ensures that all threads have finished using the barrier before it is released.". As far as my testing goes, DeleteSynchronizationBarrier() does not actually delete or release anything. The purpose of it is that it can perform a wait. Apparently the supposed usage of DeleteSynchronizationBarrier() in an app is calling it after EnterSynchronizationBarrier() has returned and before invalidating (freeing, popping stack or reusing, e. g., with new InitializeSynchronizationBarrier) the memory behind RTL_BARRIER. The problem is, when EnterSynchronizationBarrier has returned to a thread that guarantees that all the participating threads have reached the barrier. But it is not guaranteed that all of them were already woken and won't need the data from RTL_BARRIER any more. So there is no way to know when the structure can be discarded (by app) without some extra synchronization. DeleteSynchronizationBarrier() waits for all the threads which entered RtlBarrier() to be woken and be done with accessing RTL_BARRIER structure (unless all of those entered with SYNCHRONIZATION_BARRIER_FLAGS_NO_DELETE in which case DeleteSynchronizationBarrier doesn't seem to do anything). 1. https://learn.microsoft.com/en-us/windows/win32/sync/synchronization-barrier... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9267#note_119531