Interlocked.CompareExchange doesn't provide correct memory ordering

I'm trying to implement lock-free concurrent pool of objects in C#. To implement happens before behavior, I'm using CompareExchange which acts as a full memory fence (at least on x86 and ARM). Here is my code:

private sealed class Command
{
  internal Command Next;
  internal string Data;
}

private static volatile Command pool;

private static Command RentCommand()
{
  Command current, next = pool;
  do
  {
    if (next is null)
    {
      current = new();
      break;
    }

    current = next;
  }
  while (!ReferenceEquals(next = Interlocked.CompareExchange(ref pool, current.Next, current), current));

  string data = current.Data;

  // catch unexpected behavior with debugger
  if (data is not null)
    System.Diagnostics.Debugger.Break();

  current.Next = null;
  return current;
}

private static void ReturnCommand(Command cmd)
{
  cmd.Data = null;
  Command currentValue = cmd.Next = pool;
  Interlocked.CompareExchange(ref pool, cmd, currentValue);
}

There are two methods: RentCommand and ReturnCommand. The first one requests a new Command from the pool, the second one returns it back. I'm expecting that cmd.Data = null happens before cmd returned back to the pool inside of ReturnCommand. As a result, inside of RentCommand the thread should see that Data field is always null. But the debugger stops at breakpoint which is coded explicitly inside of RentCommand. CompareExchange is used on both sides: consumer and producer. So they can run concurrently (both methods can be called safely by different threads) in theory. Here is the code for test that reproduces this situation:

public static async Task Test()
        {
            static void RunTask(string taskName)
            {
                for (var i = 0; i < 40_000; i++)
                {
                    var cmd1 = RentCommand();
                    cmd1.Data = taskName + "_1";
                    Thread.Yield();
                    var cmd2 = RentCommand();
                    cmd2.Data = taskName + "_2";
                    cmd2.Data.GetHashCode();
                    ReturnCommand(cmd1);
                    ReturnCommand(cmd2);
                }
            }

            await Task.WhenAll(
                Task.Run(static () => RunTask("Task1")),
                Task.Run(static () => RunTask("Task2")),
                Task.Run(static () => RunTask("Task3")),
                Task.Run(static () => RunTask("Task4")),
                Task.Run(static () => RunTask("Task5")),
                Task.Run(static () => RunTask("Task6")),
                Task.Run(static () => RunTask("Task7")),
                Task.Run(static () => RunTask("Task8")),
                Task.Run(static () => RunTask("Task9")),
                Task.Run(static () => RunTask("Task10")),
                Task.Run(static () => RunTask("Task11")),
                Task.Run(static () => RunTask("Task12")),
                Task.Run(static () => RunTask("Task13")),
                Task.Run(static () => RunTask("Task14")),
                Task.Run(static () => RunTask("Task15")),
                Task.Run(static () => RunTask("Task16")));
        }

It seems like CPU or JIT reorders cmd.Data = null and put after CompareExchange. However, I tried to test this hypothesis and put Interlocked.MemoryBarrier() explicitly after assignment but before CompareExchange. No luck.

The test works as expected if I put [MethodImpl(MethodImplOptions.Synchronized)] on both methods. But I don't understand why? Monitor lock inserts read barrier at its beginning and write barrier in the end (regardless of other activities under the hood such as pausing thread while waiting for lock).

I found a root cause. Let's imagine that we have 3 competing threads, and two objects inside of the pool: B -> A (B references A). All three threads executing RentCommand:

1. T1 rents B (passes through CompareExchange), T2 rents A (passes through CompareExchange), T3 sees current=B, next=A but didn't pass CompareExchange yet
2. T1 returns B, T3 executes CompareExchange. This operation is successful because its current is equal to pool. However, its next points to A. CompareExchange swaps B to A successfully. However, T2 didn't return A yet. As a result, A becomes available for rent while in use.

Seems like it's typical ABA problem when trying to use lock-free algorithm.

Conclusion: thread-safe object pooling using singly linked-list cannot be implemented correctly.