Interlocked.CompareExchange on Nullable<int>

[jhudsoncedaron]

This has come up a few times in our codebase where we would really want CompareExchange on Nullable to work.

Most of the interlocked operations are not possible, but an Interlocked.Read, Interlocked.Exchange, and Interlocked.CompareExchange are possible. An Interlocked.Write here would also be very useful but there's scarcely any precedent for that. (We took a dependency on writing to a long is atomic on 64 bit).

But if there's only going to be one, CompareExchange is definitely it.

I could not check if it's possibly simply because I could not check if Nullable actually has 8 byte alignment or not. If the alignment is there, the feasibility is quite reasonable. It's mostly a problem of hammering this past the compiler:

unsafe Nullable<int> CompareExchange(ref Nullable<int> location1, Nullable<int> value, Nullable<int> comparand)
{
    delegate*<ref long, long, long> p1 = CompareExchange;
    delegate*<ref Nullable<int>, Nullable<int>, Nullable<int>> p2 = p1;
    return p2(location1, value, comparand);
}

So what's the big idea? We already have CompareExchange on a long; no reason to write the implementation twice.

Fragment from our internal discussion on the most recent case:

        // What the assignment was expected to generate:
        // shl     rsi, 0x20
        // or      rsi, 1
        // mov     [rdx + 4], rsi

        // What it actually generated:
        // mov     byte ptr [rdx], 1
        // mov     [rdx], esi
        // So I need a lock here
        lock(this) {
            systemuid ??= GetSystemUid();
        }

lazy is far too heavyweight for the insanely rare case; and calling it twice is harmless just slow. This is just one example far from being enough by itself.

[EgorBo]

I could not check if it's possibly simply because I could not check if Nullable actually has 8 byte alignment or not.

8-bytes alignment is not guaranteed for Nullable<int>, so your workaround may throw an exception on some platforms (e.g. arm64).

[jhudsoncedaron]

In which case I definitely can't provide my own implementation because it would it wouldn't work on x64 either. It would run but not actually be atomic because that is the penalty.

I could however use the union trick, which doesn't package up neatly into an API.

[colejohnson66]

The simplest solution is to just use a proper lock. Unless you’re in high-performance requiring code, a lock will perform just as fast as a CMPXCHG

[jhudsoncedaron]

Well in this case I was able to write lock(this);, but sometimes that is not a solution.

The real benefit to writing code that doesn't take locks is the lock management goes away. Sometimes there is just simply not a sensible place to put the lock. .NET made the lock management code short, but doesn't quite go away.

Raymond Chen's discussion is still relevant: https://devblogs.microsoft.com/oldnewthing/20110421-00/?p=10863

So yeah I'm just going to leave this case using a simple lock; but I have cases where I've unwrapped the nullable to get atomic access to it; and I may or may not convert some cases to the union trick in the future.

[Clockwork-Muse]

The guidelines state to avoid lock(this).

Without Interlocked support I'd probably recommend finding/writing some sort of threadsafe/atomic-capable nullable type.

[jhudsoncedaron]

@Clockwork-Muse : And if I were in a library the guidelines would be correct.