[Mono-dev] Atomic semantics with Interlocked

[Miguel de Icaza]

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 <mono-devel-list-bounces at lists.dot.net> on behalf of Vlad Brezae via Mono-devel-list <mono-devel-list at lists.dot.net>
Reply-To: Vlad Brezae <vlbrez at microsoft.com>
Date: Thursday, August 18, 2016 at 6:03 AM
To: Alex Petersen <alpeters at microsoft.com>, Marek Safar <masafa at microsoft.com>
Cc: "mono-devel-list at lists.dot.net" <mono-devel-list at lists.dot.net>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-devel-list/attachments/20160818/99006f1e/attachment.html>