Stl: <mutex>: Question about CLR support

[AlexGuteniev]

I'm seeing that shared_mutex is supported with _M_CEE, whereas mutex is not.
And both are banned on include level under _M_CEE_PURE.

What is the situation with C++ support for _M_CEE?

Are _M_CEE and _M_CEE_PURE the only .Net modes, so that other special modes like C++/CX or OneCore are usual compilation, with full C++ support?

[AlexGuteniev]

I'm also assuming regarding compatibility of mix that:

• _M_CEE without _M_CEE_PURE has also platform, such as _M_X64 defined, and must be ABI-compatible with native compilation for that platform
• _M_CEE_PURE does not necessarily assume a platform, it is .Net IL code, and it does not mix with native compilation

[StephanTLavavej]

We can get definitive answers to these questions - is this blocking any feature work?

[AlexGuteniev]

It is only blocking some speculation on how mutexes should be done for vNext.
(There should be an answer when working on vNext)

[AlexGuteniev]

Actually now it does block #52

<atomic> is not supported in _M_CEE_PURE
Supporting <latch>, <barrier>, <semaphore> without <atomic> is interesting.
If there is such need, I need to clarify some more details.

[CaseyCarter]

Actually now it does block #52

<atomic> is not supported in _M_CEE_PURE
Supporting <latch>, <barrier>, <semaphore> without <atomic> is interesting.
If there is such need, I need to clarify some more details.

/clr:pure and C++20 are mutually exclusive; no C++20 features need to support _M_CEE_PURE.

[AlexGuteniev]

Thanks, for now would be enough to know that