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