Quetions about ManualResetValueTaskSourceCore.Reset and ValueTask.

[NMSAzulX]

Hello, everyone! I am learning about ValueTask, I have referred to different people's blogs and collected some code, I still want to know some more ingenious uses of ValueTask, because it affects the project I am working on, it needs to be low-allocate.

1、Reset and Version
I have seen some uses of ValueTask, such as:

var mrvts = IValueTask...
var task  = new ValueTask(mrvts,mrvts.Version)；
await task;
mrvts.SetResult();
mrvts.Reset();

If I keep using the Reset method, will the Version overflow?

2、 What exactly does the second parameter of ValueTask do?

3、I am now implementing a highly concurrent network scenario. I need to create 100, 000 TaskCompletionSource objects in 1 second to wait for the result of the program scheduling. I wonder if new TaskCompletionSource can be optimized, such as using ValueTask instead.

4、I see that there is an official implementation of ResettableBooleanCompletionSource, which is more like a reasonable solution for low-allocate. May I ask about its usage scenario?

[NMSAzulX]

Why is it that every time I ask a question, no one answers the question? This is more than once. Did I ask a bad question? Who can tell me the real reason? Am I being blocked? This is a psychic event.🥶☠

[stephentoub]

Because many of us (myself included) are on vacation. I'll be happy to respond in January if no one else has by then.

[NMSAzulX]

Sorry to disturb everyone’s holiday. This question not very important. Have a nice holiday. When you look through your phones, we can interact with each other.
I often see your blog, ValueTask blog is written by you, right? Thank you! I'm talking to David about an optimized scene, but he seems to have been overwhelmed by me. #46006 If he is also on vacation, he should not think about ValueTask when swimming, because the throughput of sea water is greater. And He may not get any inspiration from the fish. At least I won't.

[NMSAzulX]

I envy you for going on holiday. I haven't been out for a long time. The bad thing is that time and effort didn't make me a good programmer. 😂

[AlgorithmsAreCool]

@NMSAzulX

I can try to answer some of this for you.

If I keep using the Reset method, will the Version overflow?

Yes it might, but that isn't your concern. The token is a private value sent to and from the IValueTaskSource implementation. If it overflows, it is up to the IVTS implementation to handle that.

2、 What exactly does the second parameter of ValueTask do?

the token value is a basic safety check. A key thing to understand about a ValueTask that is backed by a IValueTaskSource, is that it may only be awaited once. If you await it twice, bad things may happen. So they added this incrementing token that will help detect if someone is misusing the API.

You can find details on the design here #25182

3、I am now implementing a highly concurrent network scenario. I need to create 100, 000 TaskCompletionSource objects in 1 second to wait for the result of the program scheduling. I wonder if new TaskCompletionSource can be optimized, such as using ValueTask instead.

So....this is a lot of things to await. and more importantly, if you are using TaskCompletionSource, then you are probably not awaiting IO. This is important because if your workload is CPU bound then awaiting these tasks will run a lot slower then just running them sequentially. There may be things you can do about this.

Can you share any more details about what kind of processing you need to do?

4、I see that there is an official implementation of ResettableBooleanCompletionSource, which is more like a reasonable solution for low-allocate. May I ask about its usage scenario?

I don't know much about this, it isn't a public API. It may work for you, but I don't know about your scenario to advise.

[AlgorithmsAreCool]

I'll take a bit of time to think about your use case. But i'm sure there are good solutions.

[NMSAzulX]

There are some scenarios that are the same as those I have described, such as Redis Client.

[AlgorithmsAreCool]

@NMSAzulX

I spent some time today thinking about your design problem and I have a proposed architecture that might help.

Here is a gist of the design. It doesn't use any fancy low level async stuff, just mostly normal tasks and async await.

The printout from my machine (with server garbage collection) looks like this

└[D:\junk\BatchedAwait]> dotnet run -c Release
Hello World!
Sending a batch of 2957725 requests to server...
Sending a batch of 3477965 requests to server...
Sending a batch of 3281482 requests to server...
Sending a batch of 282828 requests to server...
Completed 10,000,000 Test Requests
Test took 6.451 Seconds 1,550,093.06 Per Second

https://gist.github.com/AlgorithmsAreCool/3a122f12493687a06ebc6ab2b5385d2b

I hope this gives you some help

[NMSAzulX]

Hey, man! I carefully tested the reusable ValueTask and got a bad result. I think I broke its structure so that it didn't get the right result. When I used valueTask.IsCompeleted to determine whether it had been completed, it finished ahead of time. It made me helpless. I spent a lot of time proving that I had done something wrong. Thanks for your example, I'm ready to use TaskCompletionSource honestly. I used to monitor the program's memory fluctuations, only a few megabytes in high concurrency, maybe I can accept this.

https://github.com/2881099/FreeRedis/tree/master/experimental/console_netcore31_newsocket/Scheduler/Task.
These are some disappointing documents, and now I've decided not to take risks until I get to know more about Task.

[AlgorithmsAreCool]

@NMSAzulX

Yeah, the infrastructure around Tasks is really really subtle and complex. But hopefully the simpler solution can work for you. 100K requests per second with individual awaits is easily doable with Task it seems.

One last note, in my example I do use TaskCompletionSource, but only once per batch instead of once per request. All the requests for a batch share the same initial task and then use a continuation to select only the response they need. I tried to keep the Task allocations as low as possible.