如果你有许多线程要做的事情，那么显然异步调用不一定比同步调用更好，因为阻塞线程只是把剩下的时间交给下一个线程（如果有的话）根据this question的答案。
我的问题是Windows什么时候决定通话阻止？据推测，并非每次调用数据库，文件系统或tcp / ip堆栈都是阻塞的，因为否则所有这些调用都需要至少10毫秒才能完成（因为线程将放弃剩余的时间片，大约10毫秒长）。但是，我们肯定有数据库调用所需的时间比完成数据库的时间短。
那么Windows如何等待确定一个呼叫是否确实是阻塞以及确定一个呼叫实际上阻塞了多少时间（例如，Windows是否使用一个小超时来确定数据库或其他资源事实上，呼叫是阻止的。）
我提出要求的真正原因是为了更好地理解它是如何工作的，这样我就能更清楚地理解同步与异步调用权衡。
答案 0 :(得分：1)
你写了，因为否则所有这些调用都需要至少10毫秒才能完成（因为线程将放弃剩余的时间片，大约10毫秒长）
这不是真的。
线程被阻止（由于IO） - ＆gt;失去剩余的时间片
让我们说，在1 MS之后，块结束，并且windows将线程重新安排到执行队列......
比方说，在2 MS之后，线程再次运行（如果所有正在运行的线程执行许多IO调用，这是合理的...这意味着它们会提前结束）。
你打电话给3 MS结束......
答案 1 :(得分：1)
在最低级别，所有 IO将是异步的，而不是同步的。
您必须访问IO的所有阻塞方法都只是使用某种类型的同步机制（即信号量）来阻塞线程，直到IO完成。
如果你有一个提供异步IO访问的API（除非它写得不好），它不会采用那种同步方法并使其异步，它只是暴露了IO的基础异步和跳过这一步骤它会阻塞直到它完成。
答案 2 :(得分：1)
通常，当您发起IO请求时，呼叫会转到内核和设备驱动程序。如果可以立即满足请求（例如，由于缓存），那么它将是。
在这种情况下，当同步IO函数要求内核等待IO完成时，立即满足等待并且线程不会阻塞。
如果不立即满足等待，Windows在更改线程上下文之前可能会或可能不会短暂旋转锁定。这是一个无证的实现细节，可能因情况而异。
请注意，使用同步或异步功能无关紧要;唯一的区别是哪些代码要求内核等待。这两种行为都是一样的。
异步调用可能比使用同步调用和多个线程提供一些性能优势，因为如果同时完成多个IO操作，您可以处理所有这些操作的结果，而无需切换线程上下文。它们还可以让您以更方便的方式构建程序;显然，这取决于您的特殊需求。后者通常更重要。
答案 3 :(得分：0)
'Windows何时判断呼叫是否阻止？
简单 - 只要它要求立即无法获得的资源。
'因为否则所有这些调用都需要至少10毫秒 完成（因为线程将放弃其余的时间 切片，大约10毫秒长。）
你不明白先发制人的多任务工作是如何运作的 - 你可能被许多，绝望误导的'线程入门-101'网站/书籍误导了。定时器中断只是可以改变线程状态的众多中断源之一。来自导致驱动程序运行的非计时器外围设备的硬件中断和线程间通信调用可以启动调度程序运行并使线程准备好等待。
我的建议是立即关闭并销毁包含关键字/短语'quantum'，'time-slice'，'round-robin'，'放弃剩余部分'的所有此类网站的链接。此外，任何提及定时器的站点都会在其他站点之前中断，或者根本不提及其他中断。
所有这些网站都是垃圾，其中有很多。