Post History

I'm not an expert on this at all, but so far there are no answers, so I'll try one.

"Synchronization" is in the context of multithreading.

For those who don't know how multithreading works: Multithreading is like having multiple CPUs run parts of the program in parallel. This runs into a problem with common data. Usually, it is difficult for multiple threads to write to the same variable, memory address, file, etc. at the same time. The program must arrange that when accessing such objects, every thread first reserves ("locks") the resource, does its work, then frees it again. The other threads basically get in line and wait for the resource to be freed, this prevents concurrent access.

Esync, Fsync, etc refer to various different algorithms/implementations of the resource locking mechanism, based on https://github.com/lutris/docs/blob/master/HowToEsync.md. You can see how a program that relies on multithreading will do a lot of locking/unlocking so there's interest in optimizing it. However, in practice, the most performance intensive Windows applications are games, and games almost always have much bigger bottlenecks (3D rendering, inefficient algorithms) than synchronization.

Esync appears to be an older and simpler approach. Newer ones like Fsync probably provide a slight performance boost, but also are more likely to cause crashes. All of these algorithms work as far as synchronization, but the APIs they use (how the windows program will ask the OS to synchronize) may be incompatible for some reason, which may lead to a program failing to work with a newer synchronization method. You may also discover implementation bugs that the OS developers accidentally introduced.

For normal users who are not interested in helping test experimental features, the reasonable approach is probably:

* Use Esync for everything
* If the program crashes with Esync, try Fsync just in case, but don't expect much. There should be very few programs that break with Esync but not others, while there's probably more that break with Fsync but work on Esync.
* Give up on the performance boost of Fsync. It's a very small increase (unless a particular, exquisitely badly developed program presents a pathological case) and will not be worth the extra troubleshooting when it breaks.

The advice is opinion more than anything, but the interaction between Windows compatibility, performance and multithreading is a very complex topic and it's hard to say anything concrete beyond this.