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

[stephentoub]

it won't install via nuget on non windows (macos + xamarin)

@ericstj, I thought we had default implementations that throw PlatformNotSupportedExceptions for these Windows-specific libs... is that not the case for this one, or is there another package that needs to be referenced to get them?

[niemyjski]

When we try and install https://www.nuget.org/packages/System.Security.AccessControl/ on xamarin projects we get "For adding package 'System.Security.Principal.Windows.4.0.0' to project 'TestExceptionLess' that targets 'monoandroid60'. Install failed. Rolling back"

Looking at it further it also references Microsoft.Win32.Primitives (>= 4.0.1)

[ericstj]

I thought we had default implementations that throw PlatformNotSupportedExceptions for these Windows-specific libs

Yes we do.

When we try and install https://www.nuget.org/packages/System.Security.AccessControl/ on xamarin projects we get "For adding package 'System.Security.Principal.Windows.4.0.0' to project 'TestExceptionLess' that targets 'monoandroid60'. Install failed. Rolling back"

That's because the xamarin platforms don't use a RID to restore. I've added more detail in the issue you opened.

Looking at it further it also references Microsoft.Win32.Primitives (>= 4.0.1)

That's fine, Win32.Primitives is cross-plat. It contains Win32Exception which is implemented everywhere.

[stonstad]

@niemyjski I see this was closed but was it resolved successfully or is it won't fix?

.Net Core 3.0, Linux, ala EventWaitHandle.

"The named version of this synchronization primitive is not supported on this platform."
Stack Trace at System.Threading.EventWaitHandle.CreateEventCore(Boolean initialState, EventResetMode mode, String name, Boolean& createdNew) ...

[stephentoub]

was it resolved successfully or is it won't fix?

Where it could be supported (e.g. Mutex), it is, and for the rest it throws PlatformNotSupportedException, by design.

[prezaei]

Hey @stephentoub, except for Mutex, what else is supported? Cheers

[stephentoub]

Just Mutex. Semaphore and EventWaitHandle don't support named primitives today on unix.