Atomic wait semantics lead to continued processing after cancellation about asyncex HOT 3 OPEN

You do bring up some good points. This would, however, be a significant breaking change.

from asyncex.

This has the same behavior as Monitor.TryEnter. If you try to enter a Monitor with 0 timeout, it will try to take the lock before returning false. So it's a matter of which convention you want to follow. But I guess it would be a little more obvious if it had a Try in the method name.

from asyncex.

My previous argument was based on the effect when not doing an atomic wait. I just needed to actually do an atomic wait for real and found some additional concerns.

When doing an atomic wait, the Lock method could throw an OperationCancelledException, but that exception isn't an error. It is the expected result when failing to acquire the lock. There are three problems with this.

1. The using statement makes it difficult to put a try/catch around the call to Lock without including other code that could raise an OperationCancelledException because of an actual cancellation.
2. The try/catch is a lot of boilerplate
3. An exception is being used for a non-error case raising concerns about the performance implications of using an exception there.

The following code demonstrates what I mean:

public async Task Example(CancellationToken ct = default)
{
	try
	{
		using(_asyncLock.Lock(new CancellationToken(true)).ConfigureAwait(false))
		{
			await SaveAsync(results, ct);
		}
	}
	catch (OperationCancelledException)
	{
		// This will catch both the expected exception from the call to Lock(), and the actual cancellation
		// from the call to SaveAsync(). To avoid this, one would need to try/catch just the Lock() while
		// saving the disposable into a variable to put into a using after the try/catch.
	}
}

I created an extension method to AsyncLock that I think shows what could be a good usage pattern. It follows a convention we established for our codebase of naming methods that do not wait *Now. Using that name isn't necessary, it just demonstrates how such a method could work. (Note that the method doesn't need to be async because it never actually waits to acquire the lock. This allows for the use of an out parameter.)

public async Task Example(CancellationToken ct = default)
{
	using(_asyncLock.LockNow(out var held))
	{
		if (!held)
			return;

		await SaveAsync(results, ct);
	}
}

from asyncex.