Add generic And<T> and Or<T> methods to System.Threading.Interlocked

[Copilot]

Summary

This PR adds generic versions of the And and Or methods to System.Threading.Interlocked as specified in API proposal #114568.

Changes

• Add generic And<T>(ref T, T) where T : struct method
• Add generic Or<T>(ref T, T) where T : struct method
• Support integer primitive types and enums backed by integer types
• Reject float/double types and floating-point backed enums
• Add appropriate error handling and messages
• Update reference assembly
• Add comprehensive theory-based tests (40+ test methods with 100+ test cases)
• Replace existing usages of Interlocked.And/Or(ref Unsafe.As...) with new generic API
• Restrict JIT intrinsic expansion to TYP_INT and TYP_LONG only
• Add TODO comment for small integer intrinsic support
• Update XML documentation to clarify floating-point restrictions
• Simplify validation logic to single-level if statement
• Security checks (CodeQL - no issues)

Implementation Details

• For 1-2 byte types (byte, sbyte, short, ushort): Uses CompareExchange-based loop (managed fallback)
• For 4-byte types (int, uint): Delegates to int And/Or with bitcast (JIT intrinsic)
• For 8-byte types (long, ulong): Delegates to long And/Or with bitcast (JIT intrinsic)
• Float/Double: Rejected via type checks
• Floating-point backed enums: Rejected via Type.GetEnumUnderlyingType() check (JIT-foldable)
• JIT Integration: Modified to only expand intrinsic for TYP_INT and TYP_LONG; other types fall back to managed
• Pattern: Follows same approach as generic CompareExchange<T>

JIT Changes

Modified importercalls.cpp to restrict intrinsic expansion:

• Only TYP_INT and TYP_LONG are expanded as atomic operations
• All other types (byte, short, float, double) fall back to managed CompareExchange loops
• Uses callType consistently for type checks
• Added TODO comment: "Implement support for XAND/XORR with small integer types (byte/short)"
• Ensures correct behavior across all supported primitive types and enums

Type Rejection

The methods reject:

• Non-primitive, non-enum types
• Floating-point primitives (float, double)
• Enums backed by floating-point types (via Type.GetEnumUnderlyingType())

The validation check is a single-level if statement with proper indentation:

if ((!typeof(T).IsPrimitive && !typeof(T).IsEnum) ||
    typeof(T) == typeof(float) || typeof(T) == typeof(double) ||
    (typeof(T).IsEnum && (typeof(T).GetEnumUnderlyingType() == typeof(float) || typeof(T).GetEnumUnderlyingType() == typeof(double))))
{
    throw new NotSupportedException(SR.NotSupported_IntegerEnumOrPrimitiveTypeRequired);
}

Documentation

The XML documentation clearly states the restrictions:

/// <typeparam name="T">
/// The type to be used for <paramref name="location1"/> and <paramref name="value"/>.
/// This type must be an integer primitive type or an enum type backed by an integer type.
/// Floating-point types (float, double) are not supported.
/// </typeparam>

Test Coverage

Converted all tests to [Theory] with [InlineData] covering:

• Multiple test cases per type: 5-10 values each including edge cases
• Negative values: Comprehensive coverage for all signed types (sbyte, short, int, long)
• Edge cases: Min/max values, zero, all-ones, alternating bit patterns
• Float/Double/Half NotSupportedException tests: Verify rejection of floating-point types
• Null reference exceptions: Separate tests for all types
• Unsupported types: Tests for non-primitive value types

Usages Replaced

Replaced 7 call sites across the codebase:

• System.Private.CoreLib/ComWrappers.cs (2 calls)
• System.Net.Http/CacheControlHeaderValue.cs (2 calls)
• System.Private.Uri/Uri.cs (1 call)
• System.Private.Uri/UriSyntax.cs (1 call)
• System.Private.Uri/UriScheme.cs (1 call)

All usages now use the cleaner generic API without Unsafe.As casts.

Test Results

✅ All 705 System.Threading tests pass (0 errors, 0 failures)

Security

✅ CodeQL analysis passed with no issues

Original prompt

We have the following public APIs in System.Threading.Interlocked class:

public static int Or(ref int location1, int value)
public static uint Or(ref uint location1, uint value)
public static long Or(ref long location1, long value)
public static ulong Or(ref ulong location1, ulong value)

public static int And(ref int location1, int value)
public static uint And(ref uint location1, uint value)
public static long And(ref long location1, long value)
public static ulong And(ref ulong location1, ulong value)

We want to add their generic versions:

public static T Or<T>(ref T location1, T value) where T : struct;
public static T And<T>(ref T location1, T value) where T : struct;

for the same types + enums backed by those types.

Similar to what we did for CompareExchange in #104558.
NOTE: this will require a bit of JIT work, e.g. NI_System_Threading_Interlocked_Or and NI_System_Threading_Interlocked_And

Create a PR in dotnet/runtime to add that. Effectively, implement this API proposal: #114568

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[EgorBo]

@copilot find existing usages of Interlocked.And(ref Unsafe.As and Interlocked.Or(ref Unsafe.As and replace them with the new API.

[Copilot]

@copilot find existing usages of Interlocked.And(ref Unsafe.As and Interlocked.Or(ref Unsafe.As and replace them with the new API.

Done! Found and replaced 7 usages across 5 files:

System.Private.CoreLib

• ComWrappers.cs: 2 calls (SetFlag/ResetFlag methods with CreateComInterfaceFlagsEx enum)

System.Net.Http

• CacheControlHeaderValue.cs: 2 calls (SetFlag method with Flags enum)

System.Private.Uri

• Uri.cs: 1 call (SetFlags method)
• UriSyntax.cs: 1 call (InternalValidate method)
• UriScheme.cs: 1 call (InitializeAndValidate method)

All calls now use Interlocked.And/Or(ref enumField, enumValue) directly without Unsafe.As casts. Libraries build successfully. (2334be3)

[EgorBo]

@copilot in importercallls.cpp for:

            case NI_System_Threading_Interlocked_Or:
            case NI_System_Threading_Interlocked_And:

can you disable the intrinsic expansion for genActualType(callType) being anything other than TYP_INT and TYP_LONG? it should fallback to managed instead.

[Copilot]

@copilot in importercallls.cpp for:

            case NI_System_Threading_Interlocked_Or:

...

Done! Modified importercalls.cpp to only expand the intrinsic when genActualType(callType) is TYP_INT or TYP_LONG. Other types now fall back to the managed CompareExchange-based implementation.

The change:

• Extracts actualType once at the beginning
• Adds check: if ((actualType != TYP_INT) && (actualType != TYP_LONG)) { break; }
• Keeps existing x86 TYP_LONG restriction before the new check
• Uses actualType in gtNewAtomicNode call

All 611 System.Threading tests pass. (256f950)

[EgorBo]

@copilot Change the added tests:

1. Add tests for float & double
2. Add tests for negative values
3. Convert tests into [Theory] with [InlineData] so they use 5-10 test values & expected results

[Copilot]

@copilot Change the added tests:

1. Add tests for float & double
2. Add tests for negative values
   ...

Done! All test changes implemented:

1. Float & double tests added: Tests now verify bitwise operations work on float/double (via bitcast to int/long)
2. Negative values: Added test cases with negative values for all signed types (sbyte, short, int, long)
3. Theory conversion: All tests converted to [Theory] with [InlineData]:
   • 5-10 test cases per type
   • Covers edge cases (min/max, zero, all-ones, alternating patterns)
   • Includes negative values for signed types
   • Separate tests for null reference exceptions

Test count increased from 611 to 712. All tests pass. (d549cdd)

[EgorBo]

used TypeCode

What does that do to inlining budgets, etc.?

Ah, that is a good question, it looks like Type.GetTypeCode(typeof(T)) is not a direct intrinsic and relies on it being inlined, so probably it's not a good choice indeed, didn't know that 🤔

[jkotas]

Right. Also, Type.GetTypeCode is legacy and has a dependency on goodies like DbNull. It does not sound right for primitive interlocked operations to have (indirect) dependency on DbNull.

[EgorBo]

Right. Also, Type.GetTypeCode is legacy and has a dependency on goodies like DbNull. It does not sound right for primitive interlocked operations to have (indirect) dependency on DbNull.

I've reverted to GetEnumUnderlyingType. Does it look good otherwise?

[jkotas]

LGTM!

[EgorBo]

@copilot address the feedback over the NotSupportedException check to make it single level.

[Copilot]

@copilot address the feedback over the NotSupportedException check to make it single level.

Done. Simplified the validation check to a single-level if statement with a compound condition. Fixed indentation and removed unnecessary nesting. (a1edac8)

[EgorBo]

/ba-g deadletter

[EgorBo]

/ba-g deadletter