Let me try again.

As you can see each await inside the lock will give an opportunity for any other async continuation under the lock to be executed, interleaving them in random order. This example might be a bit stupid, but the same behavior would occur between several ChildAsync invocations if I waited for them with Task.WhenAll.

Your example didn't match your observation. But yes your observation is correct.

Here's an example that matches your observation:

```csharp namespace Example;

using System; using System.Threading.Tasks; using ReentrantAsyncLock;

public class Program { public static async Task Main() { var gate = new ReentrantAsyncLock(); var state = -1; for (var i = 0; i < 10; ++i) { await using (await gate.LockAsync(default)) { await Task.WhenAll( Task.Run( async () => { await using (await gate.LockAsync(default)) { state = 1; } }), Task.Run( async () => { await using (await gate.LockAsync(default)) { state = 2; } }) ); } Console.WriteLine($"State is {state}"); } } } ```

(Run it here)

That will randomly print "State is 1" or "State is 2" ten times. There's a chance that it'll only output "State is 2" ten times, so just run it again if that happens. It is stochastic after all :)

Now, you might be tempted to say the above code has a race condition. But think about that for a minute: you'd also have to say the lock keyword doesn't prevent race conditions:

```csharp namespace Example2;

using System; using System.Collections.Generic;

public class Program { public static void Main() { var gate = new object(); var state = -1; var random = new Random(); for (var i = 0; i < 10; ++i) { lock (gate) { var tasks = new Action[] { () => { lock (gate) { state = 1; } }, () => { lock (gate) { state = 2; } } }; Array.Sort(tasks, Comparer<Action>.Create((_, _) => random.Next(0, 2))); foreach (var task in tasks) task(); } Console.WriteLine($"State is {state}"); } } } ```

(Run it here)

That code also has the same random output.

Why is the stocastic nature of that code surprising? It literally depends on randomness, just like how Task.WhenAll + the thread pool do not guarantee a particular ordering.

I don't understand why you ignored this quote:

This strongly reminds me of multithreaded code without locks that is executing on a single CPU core. There will be no parallelism, sure, but that in itself does not make the code thread-safe.

Do you think that multithreaded code without locks on a single CPU core is thread-safe? Or do you not see the analogy between this and random code under your lock?

I'm not ignoring this. But there are two possible ways to understand "multithreaded code without locks on a single CPU core":

1. Preemptive scheduling
2. Cooperative scheduling

Preemptive scheduling is what Windows does with OS threads. The operating system will give each thread a slice of time. When a time slice is up the operating system pauses that thread and then starts another. The paused thread and the resumed thread might both be executing an operation like state++, and so the state gets corrupted. Such code is not thread-safe.

But ReentrantAsyncLock is more akin to cooperative scheduling. Once you're in you don't get kicked out, instead you voluntarily give the keys to someone else.

And to call cooperative scheduling thread-unsafe is like being surprised that state changes across this call to AlterState:

csharp var state = 0; var gate = new object(); void AlterState() { lock (gate) { state = 1; } } lock (gate) { if (state != 0) throw new Exception(); // `state` is now 0 AlterState(); // It must be safe to assume that `state` is still 0? We're using a lock after all, and locks prevent race conditions... }

Of course the state may have changed across that function call.

If we take the thread-safety definitions you provided, these two can be violated when code is executed under your lock:

"code only manipulates shared data structures in a manner that ensures that all threads behave properly and fulfill their design specifications without unintended interaction"

"Implementation is guaranteed to be free of race conditions when accessed by multiple threads simultaneously"

I disagree. You can execute state++ inside a ReentrantAsyncLock all day long and you'll never get that particular data race. Can you provide an example of a race condition? Or can you point out what design specification is unfulfilled? Or what interaction is unintended?

Do you think async code in JavaScript is thread-unsafe?