Implement named synchronization primitives to be system wide #1237

Closed
stephentoub opened this Issue Jul 14, 2015 · 12 comments

Comments

Projects
None yet
4 participants
@stephentoub
Member

stephentoub commented Jul 14, 2015

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 #481.)

@kouvel kouvel self-assigned this Aug 6, 2015

@kouvel

This comment has been minimized.

Show comment
Hide comment
@kouvel

kouvel Aug 6, 2015

Member

I'm taking a look at this issue.

Member

kouvel commented Aug 6, 2015

I'm taking a look at this issue.

@stephentoub

This comment has been minimized.

Show comment
Hide comment

kouvel added a commit to kouvel/coreclr that referenced this issue Aug 26, 2015

Return error upon attemping to create named objects in PAL.
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 added a commit to kouvel/coreclr that referenced this issue Aug 27, 2015

Return error upon attemping to create named objects in PAL.
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 added a commit to kouvel/coreclr that referenced this issue Aug 27, 2015

Return error upon attemping to create named objects in PAL.
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 added a commit to Priya91/coreclr that referenced this issue Aug 28, 2015

Return error upon attemping to create named objects in PAL.
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

This comment has been minimized.

Show comment
Hide comment
@niemyjski

niemyjski 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 #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)..

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 #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

This comment has been minimized.

Show comment
Hide comment
@stephentoub

stephentoub Jul 25, 2016

Member

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.

Member

stephentoub commented Jul 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@niemyjski

niemyjski Jul 25, 2016

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

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

@stephentoub

This comment has been minimized.

Show comment
Hide comment
@stephentoub

stephentoub Jul 25, 2016

Member

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."

Member

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

This comment has been minimized.

Show comment
Hide comment
@stephentoub

stephentoub Jul 25, 2016

Member

I think a bug needs to be opened

Feel free to open an issue.

Member

stephentoub commented Jul 25, 2016

I think a bug needs to be opened

Feel free to open an issue.

@niemyjski

This comment has been minimized.

Show comment
Hide comment
@niemyjski

niemyjski Jul 25, 2016

@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 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

This comment has been minimized.

Show comment
Hide comment
@stephentoub

stephentoub Jul 25, 2016

Member

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?

Member

stephentoub commented Jul 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@niemyjski

niemyjski 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)

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

This comment has been minimized.

Show comment
Hide comment
@ericstj

ericstj Jul 25, 2016

Member

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.

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.

@rconde01 rconde01 referenced this issue in oleg-shilo/cs-script Oct 7, 2016

Closed

Mutex failure on linux #10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment