runtime: Interlocked.CompareExchange missing for uint, ulong and (if possible) general structs.

From @redknightlois on May 18, 2017 19:47

I recently needed to use Interlocked.CompareExchange inside a function with the following form:

        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        private bool TryClaimSlot(ref uint entryKey, int key)
        {
            var entryKeyValue = entryKey;
            //zero keys are claimed via hash
            if (entryKeyValue == 0 & key != 0)
            {
                entryKeyValue = Interlocked.CompareExchange(ref entryKey, key, 0);
                if (entryKeyValue == 0)
                {
                    // claimed a new slot
                    this.allocatedSlotCount.Increment();
                    return true;
                }
            }

            return key == entryKeyValue;
        }

problem is that it can´t be done because the Interlocked.CompareExchange<T> requires it to be a class.

Also if anyone knows a workaround for it, I would appreciate it.

Copied from original issue: dotnet/coreclr#11723

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 6
Comments: 27 (22 by maintainers)

Most upvoted comments

If you guys are gonna be adding unsigned variants to Interlocked, may I suggest that you add some sort of atomic Subtraction method? At least for unsigned, as its not too obvious as to how to do that without a subtraction method…

sunkin351 on Feb 17, 2020

algorithm that uses XOR atomically, but probably the reason is that as there are not many providing implementations of it

If you need atomic XOR (or any other bit transformation), you can trivially implement it using CompareExchange. Compared to the specialized atomic instructions, the implementation using CompareExchange is not that much slower to make it a deal breaker.

jkotas on Feb 15, 2020

From my perspective, this issue was about something actually being needed, and I see no evidence that C# developers are clamoring for Interlocked.Xor. In contrast, I’ve seen a multitude of projects implement their own And/Or, including some of ours.

Most people that need atomic Xor won’t be clamoring for it, those that don’t have them just disregard certain types of high-performance algorithms that require them. It is a completeness issue, no one will clamor for anything that they cannot implement; most will just throw their hands in the air, and you won’t hear a thing. Having said so, I haven’t stumbled on an algorithm that uses XOR atomically, but probably the reason is that as there are not many providing implementations of it, because it is a very niche thing today. For the long term, completeness is always best for a platform, but if that delays the current proposal, I would just go with the partial one.

redknightlois on Feb 15, 2020