Implement named synchronization primitives to be system wide

[stephentoub]

System.Threading.Semaphore, Mutex, and EventWaitHandle (ManualResetEvent, AutoResetEvent) all support being passed names. On Windows, these names are cross-process, with this being one of the primary mechanisms apps use to coordinate across processes. On Unix these types rely on functionality in the CoreCLR Win32 PAL, which today implements these names only as process-wide. Anyone attempting to use these types for cross-process synchronization (the primary use case) could easily find themselves with bad race conditions when running on Unix.

We should reimplement this PAL functionality to use system-wide rather than process-wide names.

(Replaces #4054.)

[kouvel]

I'm taking a look at this issue.

[stephentoub]

dotnet/coreclr#1387
dotnet/corefx#2796

[niemyjski]

@stephentoub I'm curious why this and every issue around this is closed. This is a valid use case that's needed https://github.com/dotnet/coreclr/issues/3422 Just because we now throw platform not supported exception isn't a valid fix to mark it as closed :(, unless this will never be supported. We needed a named mutex under System.Security.AccessControl but it appears that it references a ton of Win32 and System.Security.Prinicpal.Windows and this fails to install under xamarin (which now supports .net standard)..

[stephentoub]

We needed a named mutex

Named Mutexes are supported on Unix as of 1.0.

unless this will never be supported

We currently have no plans to add named synchronization primitive support on Unix to other primitives. We throw for the same reason Mono throws: there's currently no good way to support it in a robust way.

[niemyjski]

@stephentoub what about http://man7.org/linux/man-pages/man3/sem_open.3.html ?

[niemyjski]

I think a bug needs to be opened for System.Security.AccessControl package to specify that it's a windows only dependency....

[stephentoub]

what about

They can easily leak:
"POSIX named semaphores have kernel persistence: if not removed by sem_unlink, a semaphore will exist until the system is shut down."

[stephentoub]

I think a bug needs to be opened

Feel free to open an issue.

[niemyjski]

@stephentoub Do you have any recommendations for replacing this or should we just not support it on net standard as we can't guarantee it will be supported + it won't install via nuget on non windows (macos + xamarin) https://github.com/exceptionless/Exceptionless.Net/blob/master/src/Exceptionless/Utility/SingleGlobalInstance.cs