Replace Win32 PAL implementation with minipal implementation

[AaronRobinsonMSFT]

This PR removes the PAL Win32 emulation of CRITICAL_SECTION. The emulation logic is unnecessarily complicated and used both a pthread mutex and condition variable. For CoreCLR purposes a mutex is sufficient.

A new minipal API was introduced, minipal_critsect. This uses the Win32 CRITICAL_SECTION on the Windows platform and pthread_mutex_t on all other platforms. This implementation aligns with a private "critical section" defined for the GC and native AOT. All now use this new API.

The CRITICAL_SECTION associated APIs and tests in the CoreCLR PAL have been removed.

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[huoyaoyuan]

FWIW, I tested std::mutex and mtx_t on Windows. std::mutex is about the same speed of CRITICAL_SECTION, and mtx_t is 2x slower. We are unable to use std::mutex because it's not noexcept.

[AaronRobinsonMSFT]

FWIW, I tested std::mutex and mtx_t on Windows. std::mutex is about the same speed of CRITICAL_SECTION, and mtx_t is 2x slower. We are unable to use std::mutex because it's not noexcept.

It isn't just because of noexcept. On Windows std::mutex will pull in the concrt, which is a huge dependency.

mtx_t

clang on macOS doesn't support C11 threads. It isn't an option in any case.

[am11]

If the implementation is shared between:

• coreclr and nativeaot, we put it under src/coreclr/minipal.
• coreclr/natvieaot and libs/corehost/mono, we put it under src/native/minipal.

This PR is mixing the existing pattern.

[jkotas]

If the implementation is shared between:
coreclr and nativeaot, we put it under src/coreclr/minipal.
coreclr/natvieaot and libs/corehost/mono, we put it under src/native/minipal.

src/native/minipal have been used to abstract general basic services. Simple lock fits the bill. It is not necessary for everything to be switched to the minipal implementation right way. For example, the initial implementation of the timers was like that.

src/coreclr/minipal have been used for functionality that's very specific and not a general basic services, like the double mapper.

[am11]

It is not necessary for everything to be switched to the minipal implementation right way.

If there is a plan to share this impl. with other subsets, then it makes sense. Otherwise, choosing among src/coreclr/runtime, src/coreclr/minipal and src/native/minipal to share code between nativeaot and coreclr is getting vague and not how they were initially defined.

[jkotas]

This is Windows-specific code calling Windows-specific API. There is no point going through a PAL layer in cases like these.

[AaronRobinsonMSFT]

I see. The problem with this model is there is an odd consistency in files. It isn't obvious/clear on when we can avoid the PAL. If this file was clearly in a "windows" directory it would be obvious. In this case though we have 100s of lines of code that are defined/included in complex ways that make it tricky to know. If we instead just implement a PAL consistently we can use the simple rule of "only use PAL APIs". I'll change it, but I don't think this is a helpful way of writing code in a file that isn't defined as being platform specific.

See the other "Pal" functions in the same block.