c# - 异步(非阻塞)代码的可伸缩性优势是什么?

标签 c# multithreading asynchronous scalability

阻塞线程被认为是一种不好的做法,主要原因有两个:

  1. 线程消耗内存。
  2. 线程通过上下文切换消耗处理时间。

以下是我因这些原因而遇到的困难:

  1. 非阻塞的异步代码也应该消耗几乎相同数量的内存,因为调用堆栈应该保存在执行异步调用之前的某处(上下文保存,之后全部)。如果线程效率非常低(在内存方面),为什么 OS/CLR 不提供更轻量级的线程版本(仅保存调用堆栈的上下文而不保存其他内容)?这不是解决内存问题的更简洁的解决方案,而不是迫使我们以异步方式重新构建我们的程序(这要复杂得多,更难理解和维护)吗?

  2. 当线程被阻塞时,操作系统会将其置于等待状态。操作系统不会上下文切换到 sleep 线程。由于线程生命周期的 95% 以上都花在 sleep 上(假设这里是 IO 绑定(bind)应用程序),性能损失应该可以忽略不计,因为线程的处理部分可能不会被操作系统抢占,因为它们应该跑得很快,做的工作很少。所以在性能方面,我也看不到非阻塞方法有太多好处。

我在这里遗漏了什么或者为什么这些论点有缺陷?

最佳答案

Non-blocking, async code should also cost pretty much the same amount of memory, because the callstack should be saved somewhere right before executing he async call (the context is saved, after all).

不会await 发生时保存整个调用堆栈。为什么您认为需要保存整个调用堆栈? 调用堆栈是延续的具体化等待任务的延续不是等待的延续。 await 的延续在栈上。

现在,很可能是这样的情况,即当给定调用堆栈中的每个异步方法都已等待时,相当于调用堆栈的信息已存储在每个任务的延续中。但是这些延续的内存负担是垃圾收集的堆内存,而不是一百万字节的已提交堆栈内存块。延续状态大小是任务数量大小的n阶;无论您是否使用线程,线程的负担都是一百万字节。

if threads are significantly inefficient (memory-wise), why doesn't the OS/CLR offer a more light-weight version of threads

操作系统会。它提供纤维。当然,纤维仍然有一个堆栈,所以这可能不是更好。我想你可以有一个带有小堆栈的线程。

Wouldn't it be a much cleaner solution to the memory problem, instead of forcing us to re-architecture our programs in an asynchronous fashion

假设我们让线程——或者就此而言,进程——变得更便宜。那仍然没有解决同步访问共享内存的问题。

就其值(value)而言,我认为如果流程更轻便会更好。他们不是。

此外,这个问题有些自相矛盾。您正在处理线程,因此您已经愿意承担管理异步操作的负担。一个给定的线程必须能够在它产生第一个线程请求的结果时告诉另一个线程。线程已经隐含了异步,但异步并不隐含线程。在语言、运行时和类型系统中内置异步架构只会让那些不幸不得不编写管理线程代码的人受益。

Since way over 95% of the thread's life cycle is spent on sleeping (assuming IO-bound apps here), the performance hit should be negligible, since the processing sections of the thread would probably not be pre-empted by the OS because they should run very fast, doing very little work.

为什么你要雇佣一个 worker (线程)并支付他们的薪水坐在邮箱旁(让线程休眠)等待邮件到达(处理 IO 消息)? IO 中断首先不需要线程。 IO 中断存在于线程级别以下的世界中。

不要雇佣一个线程来等待IO;让操作系统处理异步IO操作。雇用线程来执行异常大量的高延迟 CPU 处理,然后为您拥有的每个 CPU 分配一个线程。

现在我们来回答您的问题:

What are the benefits of async (non-blocking) code?

  • 不阻塞 UI 线程
  • 让编写生活在高延迟世界中的程序变得更容易
  • 更有效地利用有限的 CPU 资源

但让我用一个类比来重新表述这个问题。你在经营一家 express 公司。有很多订单进来,很多交货出去,你不能告诉客户你不会接受他们的交货,直到每次交货都在他们完成之前。哪个更好:

  • 雇用五十个人接电话、取包裹、安排投递和投递包裹,然后要求其中 46 人始终闲置

    <
  • 雇用四个人,一开始让他们每个人都非常好,一次做一点点工作,这样他们就能始终响应客户的要求,其次,真的善于保留他们 future 需要做的工作的待办事项 list

后者对我来说似乎更划算。

关于c# - 异步(非阻塞)代码的可伸缩性优势是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34799081/

相关文章:

c# - ASP.NET MVC 将 ID 传递给 ActionLink

c# - 非基于比较的排序问题的排序算法?

c - getaddrinfo_a 线程安全吗?

c库函数获取事件线程数

Java使用对象作为监视器,这个对象是不是太重了?

javascript - 重用通过解构创建的对象字面量

javascript - 有条件地调用一个 promise (或不调用),但将任一结果返回给另一个 promise

c# - 高级 C# 字符串比较

c# - 函数和列表<string>

c# - 读取非常大的文本文件,我应该合并异步吗?