[Mono-dev] Atomic semantics with Interlocked

Jon Purdy jopur at microsoft.com
Thu Aug 18 16:58:41 UTC 2016

Yeah, it seems most Interlocked functions are assumed to use full fences, like their Windows API equivalents. (That's why there are *Acquire, *Release, and *NoFence variants in the Windows API.) Same goes for volatile.

Changing it will probably affect performance negatively, but if it's for correctness, we have no choice.

Could we also add the Acquire/Release/NoFence variants for our internal use?

From: Mono-devel-list <mono-devel-list-bounces at lists.dot.net<mailto:mono-devel-list-bounces at lists.dot.net>> on behalf of Vlad Brezae via Mono-devel-list <mono-devel-list at lists.dot.net<mailto:mono-devel-list at lists.dot.net>>
Reply-To: Vlad Brezae <vlbrez at microsoft.com<mailto:vlbrez at microsoft.com>>
Date: Thursday, August 18, 2016 at 3:03 AM
To: Alex Petersen <alpeters at microsoft.com<mailto:alpeters at microsoft.com>>, Marek Safar <masafa at microsoft.com<mailto:masafa at microsoft.com>>
Cc: "mono-devel-list at lists.dot.net<mailto:mono-devel-list at lists.dot.net>" <mono-devel-list at lists.dot.net<mailto:mono-devel-list at lists.dot.net>>
Subject: [Mono-dev] Atomic semantics with Interlocked


        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 ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-devel-list/attachments/20160818/b6ac968d/attachment.html>

More information about the Mono-devel-list mailing list