Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement named synchronization primitives to be system wide #4370

Closed
stephentoub opened this issue Jul 14, 2015 · 16 comments
Closed

Implement named synchronization primitives to be system wide #4370

stephentoub opened this issue Jul 14, 2015 · 16 comments
Assignees

Comments

@stephentoub
Copy link
Member

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 kouvel self-assigned this Aug 6, 2015
@kouvel
Copy link
Member

kouvel commented Aug 6, 2015

I'm taking a look at this issue.

@stephentoub
Copy link
Member Author

kouvel referenced this issue in kouvel/coreclr Aug 26, 2015
Update PAL APIs that create named objects (mutex, semaphore, event, file mapping) to return a not-supported error code. It was decided to not support cross-process synchronization in PAL at present time due to complexities involved in reliably emulating Windows' behavior. @stephentoub has already made changes on the FX side to throw PlatformNotSupportedException in these cases.

Related to issue #1237.
kouvel referenced this issue in kouvel/coreclr Aug 27, 2015
Update PAL APIs that create named objects (mutex, semaphore, event, file mapping) to return a not-supported error code. It was decided to not support cross-process synchronization in PAL at present time due to complexities involved in reliably emulating Windows' behavior. @stephentoub has already made changes on the FX side to throw PlatformNotSupportedException in these cases.

Related to issue #1237.
kouvel referenced this issue in kouvel/coreclr Aug 27, 2015
Update PAL APIs that create named objects (mutex, semaphore, event, file mapping) to return a not-supported error code. It was decided to not support cross-process synchronization in PAL at present time due to complexities involved in reliably emulating Windows' behavior. @stephentoub has already made changes on the FX side to throw PlatformNotSupportedException in these cases.

Related to issue #1237.
Priya91 referenced this issue in Priya91/coreclr Aug 28, 2015
Update PAL APIs that create named objects (mutex, semaphore, event, file mapping) to return a not-supported error code. It was decided to not support cross-process synchronization in PAL at present time due to complexities involved in reliably emulating Windows' behavior. @stephentoub has already made changes on the FX side to throw PlatformNotSupportedException in these cases.

Related to issue #1237.
@niemyjski
Copy link

niemyjski commented Jul 25, 2016

@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
Copy link
Member Author

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
Copy link

@niemyjski
Copy link

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

@stephentoub
Copy link
Member Author

stephentoub commented Jul 25, 2016

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
Copy link
Member Author

I think a bug needs to be opened

Feel free to open an issue.

@niemyjski
Copy link

@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
Copy link
Member Author

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
Copy link

niemyjski commented Jul 25, 2016

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
Copy link
Member

ericstj commented Jul 25, 2016

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
Copy link

stonstad commented Jan 29, 2020

@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
Copy link
Member Author

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
Copy link

prezaei commented Aug 2, 2020

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

@stephentoub
Copy link
Member Author

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

@ghost ghost locked as resolved and limited conversation to collaborators Jan 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants