libde265: Use process-local sync primitives on Windows.

[nsivov]

This issue came up when running libheif+libde265 using Wine,
manifesting as severe performance degradation.

Windows-specific code is using Win32 mutex for cross thread
synchronization, both directly and to implement conditional variables.
This is problematic on Wine because it causes global state change
exchange on every mutex access. On Wine NT objects state is
managed in a separate resident process, each user process communicates with it
to update object state. High frequency access is going to cause
performance problems as a result. Performance will degarde further
if multiple process are running at the same time, each using same
large amount of such calls.

Proposed change is using API that is available since Windows Vista.

[farindk]

Thank you for this. That's really helpful since I am not a regular Windows (or Wine) user.

I am wondering: libde265 was written before C++11 was widely available, but now, we could simply use std::mutex and std::condition_variable instead. Do you know their performance on Windows compared to your proposal?
If needed, I could make the changes and you could maybe benchmark them on Windows?

These references seem to suggest that using the C++11 types might be even better:
Why did CRITICAL_SECTION performance become worse on Win8
How is CONDITION_VARIABLE implemented?

[nsivov]

Yes, I think this will work just fine. I see libde265 is already using std::mutex for library init/deinit functions, so it won't be a new addition. The build I tried was using VS 2022, using std::mutex and std::condition_variable will link to msvcp140.dll for sync functions, and already does for existing std::mutex.

Regarding CRITICAL_SECTION on Win8 point, I checked what we have implemented in Wine for CRT, and we do indeed use CONDITIONAL_VARIABLE + SRW for those functions, for newer runtime versions. So that checks out.

So yes, I'd be happy to test the changes.