Inter-process Mutex doesn't work for processes of different architectures on Apple Silicon #62140
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
dotnet-issue-labeler
bot
added
the
untriaged
|
cc: @kouvel |
|
Tagging subscribers to this area: @mangod9 Issue DetailsDescriptionIt's impossible to synchronize .NET processes of different architectures (x64 and aarch64) using Reproduction StepsLet's create the following simple console application: using System;
using System.Threading;
class Program {
static void Main(string[] args)
{
Mutex mutex = null;
try
{
mutex = new Mutex(false, "Global\\MyUniqueMutexName");
mutex.WaitOne();
Thread.Sleep(TimeSpan.FromSeconds(60));
}
catch (Exception ex) { Console.WriteLine(ex); }
finally { mutex?.ReleaseMutex(); }
}
}Then let's build it on Apple Silicon using two toolsets with .NET 6 - for x64 and aarch64. And then launch them sequentially in any order. Expected behaviorBoth instances of the application run successfully and terminate ~60 seconds after the start of the first one (the second instance waits for the global mutex acquired by the first one). Actual behaviorThe second application is finished intermediately with following message Regression?No response Known WorkaroundsI don't know any workarounds Configurationand Other informationNo response
|
|
Probably the issue is that the page size is different and the code is currently strict about the size of the shared memory file, which is based on the page size. I'll see if something can be done to fix it. |
|
@kouvel Hi! It uses different types on macOS x64 & macOS ARM64, isn't it? runtime/src/coreclr/pal/src/include/pal/mutex.hpp Lines 123 to 129 in 4822e3c |
|
It should be using file locks for both, I believe OSX doesn't have pthread robust mutexes |
|
Okay I checked, the error is coming from here runtime/src/coreclr/pal/src/sharedmemory/sharedmemory.cpp Lines 705 to 708 in 4822e3c |
|
Yea that would most likely be because the page size is different between x64 and arm64. The file size is set to the page size. |
…sses - The page size is different between arm64 processes and emulated x64 processes - The shared memory file size is set to the page size and there was a strict check on the file size, leading to an exception from the second process of a different arch that tries to share the same mutex - Made the file size check less strict, and allowed an arch to increase but not decrease the file size such that it can be mapped at page size granularity - Fix for dotnet#62140 in main
…sses - The page size is different between arm64 processes and emulated x64 processes - The shared memory file size is set to the page size and there was a strict check on the file size, leading to an exception from the second process of a different arch that tries to share the same mutex - Made the file size check less strict, and allowed an arch to increase but not decrease the file size such that it can be mapped at page size granularity - Fix for dotnet#62140 in main
ghost
added
the
in-pr
…sses (#62764) - The page size is different between arm64 processes and emulated x64 processes - The shared memory file size is set to the page size and there was a strict check on the file size, leading to an exception from the second process of a different arch that tries to share the same mutex - Made the file size check less strict, and allowed an arch to increase but not decrease the file size such that it can be mapped at page size granularity - Fix for #62140 in main
…sses (#62765) - The page size is different between arm64 processes and emulated x64 processes - The shared memory file size is set to the page size and there was a strict check on the file size, leading to an exception from the second process of a different arch that tries to share the same mutex - Made the file size check less strict, and allowed an arch to increase but not decrease the file size such that it can be mapped at page size granularity - Fix for #62140 in main
ghost
removed
the
in-pr
|
Fixed by #62765, should be available in the next release (SDK 6.0.102 / runtime 6.0.2). Both the x64 and arm64 runtimes would need to be updated for them to be able to synchronize on a named mutex. |
ghost
locked as resolved and limited conversation to collaborators
Description
It's impossible to synchronize .NET processes of different architectures (x64 and aarch64) using
System.Threading.Mutexon Apple SiliconReproduction Steps
Let's create the following simple console application:
Then let's build it on Apple Silicon using two toolsets with .NET 6 - for x64 and aarch64.
And then launch them sequentially in any order.
Expected behavior
Both instances of the application run successfully and terminate ~60 seconds after the start of the first one (the second instance waits for the global mutex acquired by the first one).
Actual behavior
The second application is finished intermediately with following message
Regression?
No response
Known Workarounds
I don't know any workarounds
Configuration
and
Other information
No response
The text was updated successfully, but these errors were encountered: