Review workaround for Named mutex: Use flock instead of pthread process-shared mutex

[jeffhandley]

Cleanup Issue-URLs in Code · Issue #63902 · dotnet/runtime identified a workaround in place from 2016 and it's unclear if the backing issue that necessitated the workaround has been resolved.

• The original issue was: [ARM/Linux] paltest_namedmutex_test1 hangs · Issue #6014 · dotnet/runtime
• The PR that applied the workaround was: Named mutex: Use flock instead of pthread process-shared mutex in som… by kouvel · Pull Request #6015 · dotnet/coreclr

runtime/src/coreclr/pal/src/include/pal/mutex.hpp

Lines 123 to 128 in f04a242

	// - Temporarily disabling usage of pthread process-shared mutexes on ARM/ARM64 due to functional issues that cannot easily be
	// detected with code due to hangs. See https://github.com/dotnet/runtime/issues/6014.
	// - On FreeBSD, pthread process-shared robust mutexes cannot be placed in shared memory mapped independently by the processes
	// involved. See https://github.com/dotnet/runtime/issues/10519.
	// - On OSX, pthread robust mutexes were/are not available at the time of this writing. In case they are made available in the
	// future, their use is disabled for compatibility.

The workaround should be evaluated to determine if it's still necessary. With the findings, we should either update the code to remove the workaround, or the code comment to reference an open issue for tracking when we can remove the workaround.

/cc @deeprobin

[janvorli]

It looks like the issue in glibc causing the was fixed in version 2.24, our minimum supported version for arm/arm64 is now larger than that. So we can remove the workaround now.