由于第二个进程是I / O绑定,所以似乎适合于异步任务.这导致我几个问题：
>由于异步任务不能在单独的线程上运行,所以在更新此列表时似乎不需要任何类型的锁定,对吗？
>另一方面,我们可以假设异步任务永远不会在单独的线程上运行？
>我在谈论一个Windows窗体应用程序.也许在将来我希望它作为控制台应用程序运行它. AFAIK,在控制台应用程序中异步任务运行在单独的线程上.如果在单独的线程上运行,请问任务的首选成语是什么？这样我可以在必要时建立一个锁.
>事实上,我不知道我是否真的需要一个锁,让我想知道这是否是最好的设计.坚持Task.Run()即使是这种IO绑定代码也是有道理的吗？
解决方法
Since async tasks don’t run on separate threads,it seems I don’t need
any kind of lock when updating this list,right?
不能保证没有使用Task.Run并标记他的方法异步. IO绑定的异步任务很可能不会在幕后使用某种线程,but that isn’t always the case.您不应该依赖它来代码的正确性.您可以确保您的代码通过使用不使用ConfigureAwait(false)的另一个异步方法包装在UI线程上运行.您可以随时使用框架中给出的并发集合.也许ConcurrentBag或BlockingCollection可以满足您的需求.
AFAIK,in console applications Async tasks run on separate threads.
What’s the preferred idiom to ask a task if it’s running on a separate
thread?
那是不正确的只有因为它们在控制台应用程序中,自己的异步操作不会在单独的线程上运行.简单地说,控制台应用程序中的默认TaskScheduler是默认的ThreadPoolTaskScheduler,它将队列线程池线程上的任何延续,因为控制台没有这样的实体称为ui线程.一般来说,it’s all about SynchronizationContext
The fact that I don’t know if I really need a lock makes me wonder
wether this is the best design or not. Would it make sense to stick to
Task.Run() even for this kind of IO bound code?
当然不.你不知道的事实是你发布这个问题的原因,以及我们试图帮助的原因.
没有必要使用线程池线程做异步IO. IO中异步的全部事实是,您可以在处理请求时释放执行IO的调用线程来处理更多工作.
