task.yield usage scenarios research

Transfer of executive power: Task.Yield, Dispatcher.Yield - walterlv , Yi Tsai's blog bead front. Students can jump directly over to see.

Sorry that I did not find in it Task.Yielda suitable application scenarios. About Task.Yieldscenarios also have to debate, showing that this thing must be very sad. This paper tried Task.Yieldseveral usage scenarios, see if you can become more elegant code.

Sitting next to MVP unworthy sequel, fear and trepidation. .


ReferenceSource see which Task.Yieldmethod will return a directYieldAwaitable

If your code is written so

Here Insert Picture Description

So this time it will sell its own thread, and then come up with a thread from the thread pool to continue the follow-up code

So the question is, what is suitable for useTask.Yield

1. separate thread to do large-scale computing

Here Insert Picture Description

You might think of using Task.Yieldto open a background thread to do large-scale computing

Here Insert Picture Description

But in fact, we can use more common Task.Runinstead.

Two way effect on the map in most cases is the same.

So where is not the same place it? The first written in synchronization context will be used in subsequent calculations, while the second does not

Of course, if you are developing WPF program, and that is time-consuming calculation on the UI thread, 可以choose the first.

Note: Task.Yieldthere is no ConfigureAwaitway we can see its design goal is to synchronize the context of the work

2. UI time-consuming operation, anti-Caton

The previous section proposes an operational scenario is through Task.Yielda "slice" of the UI time-consuming operation to prevent Caton.

But at least for WPF program, here it is clearly better solutions

Here Insert Picture Description

or

Here Insert Picture Description

In the UI thread Dispatcher.Yieldand Task.Yieldare equivalent, but Dispatcher.Yieldhave an extra refinement of the priority control

3. It's really sad, sad to only grammar optimization

研究之后我坚定了这个方法的鸡肋情况,绞尽脑汁能想到的就只有一些语法层面的简化

例如对于如下的循环中进行简写

Here Insert Picture Description

Here Insert Picture Description

这部分的代码简化后还是看着很清晰的

还有一种情况是在接口约束了返回值为Task的情况下,实现中没有异步时可以使用Task.Yield满足接口约束
Here Insert Picture Description

当然你也可以使用Task.FromResult进行替代

Here Insert Picture Description

不过这两者存在着是否进行线程切换的细微差别,大部分情况下,更少的线程切换(即Task.FromResult)是更优的

小结

Task.Yield可以快速便捷的出让线程的使用权,但是在实际应用上(至少是WPF)缺少较好的使用场景。

参考链接:


本文会经常更新,请阅读个人博客原文: https://xinyuehtx.github.io/ ,以避免陈旧错误知识的误导,同时有更好的阅读体验。

Creative Commons License This work is Creative Commons Attribution - NonCommercial - ShareAlike 4.0 International License Agreement for licensing. Welcome to reprint, use, repost, but be sure to keep the article signed by Huang Tengxiao (containing links: https://xinyuehtx.github.io/ ), shall not be used for commercial purposes, be sure to publish the same work based on the paper license modification. If you have any questions, please contact me .

Published 68 original articles · won praise 0 · Views 2942

Guess you like

Origin blog.csdn.net/htxhtx123/article/details/104338398