Mark the asynchronous incompatible code obsolete

[lbgitjp]

When I convert my project to asynchronous,
I found the class ReaderWriterLockSlim doesn't work well in asynchronous function, below code is not work well, ReaderWriterLockSlim should be replaced with SemaphoreSlim,

                        ReaderWriterLockSlim_Obj.EnterWriteLock();
                        
                        try
                        {
                            await WebSocket_Obj.SendAsync(text, WebSocketMessageType.Text, true, CancellationToken.None);
                        }
                        finally
                        {
                            ReaderWriterLockSlim_Obj.ExitWriteLock();
                        }

And the compiler doesn't show a warning or an error.

I think runtime as a core library, you can't make yourself code don't work well with yourself code, every class in the core library should work well in the asynchronous function.

So in order to make the system more robust, the code such as ReaderWriterLockSlim should be improved or be obsoleted.

Thanks.

[teo-tsirpanis]

Hello @lbgitjp, synchronous-only synchronization primitives like ReaderWriterLockSlim still have their use cases outside asynchronous code. You can find asynchronous editions of them on https://github.com/microsoft/vs-threading.

[lbgitjp]

Thank you, I have seen that project.

That project's is not so good for me, they add many new class, they better add 'Async' to a class's method, like websocket.Send(Async), make a class can work well both in synchronous and asynchronous.

I think the better way is don't add any class or method, make the existing class automatically adapt synchronous and asynchronous.

[Xyncgas]

you can also use System.Threading.Channels

[lbgitjp]

Thank you, I hear System.Threading.Channels first time, I will learn it.

[alexrp]

Making ReaderWriterLockSlim usable in asynchronous context is not possible. Even if you ignore the fact that its API surface is inherently thread-affine, there is still the issue that its locking semantics are defined to be thread-affine and changing that would be breaking.

This is true for most synchronization primitives in System.Threading; SemaphoreSlim is an exception. Unlike the others, its documentation explicitly states:

The SemaphoreSlim class doesn't enforce thread or task identity on calls to the Wait, WaitAsync, and Release methods.

When you're porting a synchronous code base to async/await, you have to very carefully audit any use of synchronization primitives.

Making these 'old' synchronization primitives obsolete doesn't make sense. They're still perfectly functional and useful in synchronous code.

---

By the way, replacing ReaderWriterLockSlim usage with SemaphoreSlim is very suspect to me. I can only imagine that making sense if you were using ReaderWriterLockSlim as a simple lock/Monitor (i.e. not using its read lock at all), which would be rather bizarre.

[lbgitjp]

Thank you, I will use it carefully.
If it can't work well, I will rollback to synchronize.

[lbgitjp]

I think almost everyone's project will be converted to asynchronous one day, just like me, because almost every project will use one
of the network/filesystem/database.

If they do convert, the complier show no error, just ok，their projects seems run good, but their project actually have potential problems.

Mark the asynchronous incompatible code obsolete, the users still can use it, but prompts them, they use some bad code.

By mark the asynchronous incompatible code obsolete, you encourage users to use asynchronous code as much as possible, do not use synchronous code.

[Clockwork-Muse]

... perhaps for something like this we should have an analyzer that could warn if you called a synchronous version of an async api inside an async context?

[lbgitjp]

Thanks,
ReaderWriterLockSlim is a Lock, i don't think a lock shoud distinguish between synchronous lock and asynchronous lock,
a lock should can lock anyone in any location at any time,
before asynchronous(async/await) appears in .net runtime, ReaderWriterLockSlim can do it's job well(with whole .NET runtime),
after asynchronous appears in .net runtime, ReaderWriterLockSlim can't do it's job well (only can work with part of the .NET runtime), So ReaderWriterLockSlim is not a competent lock , should not be used again.

[Clockwork-Muse]

You can use all the traditional sync locks in an async method IFF you release them all before you call await (The compiler will yell at you if you attempt to do so, but there are a few ways to still shoot yourself in the foot). That being the case, there are a few situations where you want to use them, especially if you can guarantee that your locks will only be held a short while.

[Xyncgas]

Synchronous code is what builds asynchronous code, without .NET's help, you can still build your own asynchronous little state machine in c++ or assembly.

Synchronous code is less complex due to the lack of such state machine

[lbgitjp]

Thanks,
But today, you will see most new project will go to async, in order to adapt to these new projects, most of us should use asynchronous.
Synchronous code for network/filesystem/database is not so good.

[TonyValenti]

While marking it obsolete is a bad idea, I think having some attribute that would cause a warning if used in an async context is a good idea. Also, the flip side of that, having an attribute that warns if a class is only used on one thread, is a good idea.

[Xyncgas]

today, you will see most new project will go to async, in order to adapt to these new projects, most of us should use asynchronous.

You can turn any operations asynchronous in c# by adding async to it, but what happens next?

If there is hardware concurrency and you can use it, then you will expect there to be some sort of call back from the driver therefore you just stop whatever you are executing and return for now (they will call you back) and c# does this for you by creating a state machine that manages this event
If there is software concurrency, it would means that you are going to wait on another thread and call back to the main thread

I like that the idea of you don't get notified if something doesn't support asynchronous is bad
but I also think you just know if the method doesn't support await

[Clockwork-Muse]

While marking it obsolete is a bad idea, I think having some attribute that would cause a warning if used in an async context is a good idea.

The only thing that's actually a problem is thread-affine locks, and only if you're holding a lock and call await (and the compiler will attempt to warn you). There's a number of situations where a lock held for a short time is expected.

Also, the flip side of that, having an attribute that warns if a class is only used on one thread, is a good idea.

Async code is never guaranteed to run on more than one thread, outside of scenarios that explicitly start a new Thread. Anything that relies on Task might execute on a single thread, effectively. If you have a simple console app that makes web requests, there isn't going to be a second thread at all.

[Xyncgas]

There's a number of situations where a lock held for a short time is expected.
For example, the kind of locks that implement a while loop to wait

Async code is never guaranteed to run on more than one thread
javascript async is one example

[Xyncgas]

https://docs.microsoft.com/en-us/dotnet/standard/asynchronous-programming-patterns/calling-synchronous-methods-asynchronously