Support inter-process named mutexes in managed Mutex implementation

[CoffeeFlux]

Update in-process named mutexes are now implemented since #55199 For WebAssembly and ios/Android this is sufficient.

We may still want to implement inter-process named mutex emulation using a mechanism similar to https://github.com/dotnet/runtime/blob/main/src/coreclr/pal/src/include/pal/mutex.hpp

As discussed in #55199 (comment) the approach would be to cherrypick the support from the CoreCLR PAL into a src/libraries PAL implementation.

---

Original
Some tests rely on this behavior, and so now with Mono migrating implementations they are temporarily disabled.

[lambdageek]

Edit Ah, my mistake. This is strictly more than what Mono could do before. Thanks for clarifying Stephen.

---

This is just for in-process named mutexes. Not inter-process named mutexes on non-Windows.

[stephentoub]

This is just for in-process named mutexes. Not inter-process named mutexes on non-Windows.

Note that coreclr supports interprocess named mutexes on Unix. If the goal here is to be able to switch coreclr to use the managed implementation as well, that support needs to be brought to the managed implementation as well, at which point hopefully it would also work on mono.

[uweigand]

This is now also causing problems for our experimental s390x port (features/s390x in runtimelab), because we use the Mono runtime for everything on our platform. After this change, we now see failures due to use of named Mutexes in parts of the .NET SDK itself. For example, "dotnet new console" now fails with:

System.PlatformNotSupportedException: The named version of this synchronization primitive is not supported on this platform.
   at System.Threading.Mutex.CreateMutexCore(Boolean initiallyOwned, String name, Boolean& createdNew)
   at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
   at Microsoft.TemplateEngine.Cli.New3Command.EnsureEntryMutex(String hivePath, ITemplateEngineHost host)
   at Microsoft.TemplateEngine.Cli.New3Command.Run(String commandName, ITemplateEngineHost host, ITelemetryLogger telemetryLogger, New3Callbacks callbacks, String[] args, String hivePath)
   at Microsoft.DotNet.Tools.New.NewCommandShim.Run(String[] args)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)

Similarly, the roslyn compile server code uses named mutexes for serialization (see e.g. src/Compilers/Shared/BuildServerConnection.cs) that now cause failures. Now I understand that the old implementation in Mono was not really complete, but at least it allowed these tasks to operate ...

What is the recommended way forward here? Is there a plan to add full support for named Mutexes to the managed implementation? Or should we try to work around this by eliminiating use of named Mutexes in the templating code and roslyn?

[CoffeeFlux]

The Roslyn code looks like it was adjusted to work properly with in-process named mutexes only, so adding support for that to the managed implementation would unblock you (and allow us to re-enable a lot of the test suite). I'd like to see that happen before 6.0, but I don't have immediate plans to implement it.

I don't think adding support for in-process named mutexes would be too complicated, if that's of any interest on your end? We would certainly take the change in Mono. I'll be busy with wasm work for the next couple sprints, so I would not expect any more threading implementation work on my end for another month or two.

[uweigand]

The Roslyn code looks like it was adjusted to work properly with in-process named mutexes only, so adding support for that to the managed implementation would unblock you (and allow us to re-enable a lot of the test suite). I'd like to see that happen before 6.0, but I don't have immediate plans to implement it.

I don't think adding support for in-process named mutexes would be too complicated, if that's of any interest on your end? We would certainly take the change in Mono. I'll be busy with wasm work for the next couple sprints, so I would not expect any more threading implementation work on my end for another month or two.

It took me a while to get to that, sorry. I've now posted a PR implementing this suggestion. Let me know if there's anything I should be doing different. Thanks!