Hello Vlad, Good question, I suspect this might be caused by the processor semantics being slightly different than Intel which is where .NET was originally designed to run.
Given that Mono is using ReferenceSource due to its API surface, and that .NET ReferenceSource has never ran on an ARM64 device, we should do the following: · We should get our patches on our forked code of the BCL to make sure that we work correctly. · We should also notify the .NET team of the changes that we had to do in our fork, I believe this will apply to the CoreFX folks, not sure if the ReferenceSource version will care about those changes. From: Mono-devel-list <[email protected]> on behalf of Vlad Brezae via Mono-devel-list <[email protected]> Reply-To: Vlad Brezae <[email protected]> Date: Thursday, August 18, 2016 at 6:03 AM To: Alex Petersen <[email protected]>, Marek Safar <[email protected]> Cc: "[email protected]" <[email protected]> Subject: [Mono-dev] Atomic semantics with Interlocked Hello, Lately I’ve been investigating a thread pool related hang on arm64 which I tracked it down to some missing memory barriers. It seems that, although the documentation doesn’t seem to imply memory fences for Interlocked functions, the thread pool MS code assumes it does. How should we proceed with the fix ? Get MS to follow their documentation in reference source and explicitly use a memory barrier where needed ? Add memory barriers explicitly on our own bcl ? Get the Interlocked icalls to do an additional memory barrier so we leave managed code intact ? Vlad
_______________________________________________ Mono-devel-list mailing list [email protected] http://lists.dot.net/mailman/listinfo/mono-devel-list
