【问题标题】:Asynchronous programming and interrupts exception handlers异步编程和中断异常处理程序
【发布时间】:2019-08-12 21:54:31
【问题描述】:

我是编程新手,只是一个关于异步编程实际工作原理的问题。 我们知道中断是异步发生的,因为来自 I/O 设备的信号是 处理器外部。例如,当处理器执行完一条指令,并且处理器注意到中断引脚已经变高(例如网络适配器通知有数据来),从系统总线读取异常号,然后调用相应的中断处理程序。当处理程序返回时,它将控制权返回给下一条指令。 所以它需要硬件支持。 (分配给 I/O 的专用管脚) 那么异步编程如何在没有硬件支持的情况下工作,操作系统如何向当前进程发送“Hi the result is ready, come and get it”的“通知”。 据我了解,如果没有硬件支持,我们只能通过多线程或多进程来实现。

【问题讨论】:

  • 多线程(至少,常见的抢先式风格)也使用中断——具体来说,当当前时间片结束并且调度程序需要选择另一个时,会引发一个定时器中断线程为下一个量程执行。

标签: multithreading asynchronous exception operating-system


【解决方案1】:

所以它需要硬件支持。 (分配给 I/O 的专用引脚)那么异步编程如何在没有硬件支持的情况下工作,操作系统如何向当前进程发送“结果准备就绪,来获取它”的“通知”。据我了解,没有硬件支持,只能通过多线程或多进程来实现。

了解(通常)有许多层被(通常是有意抽象的)接口隔开。从最低层到最高层,这些层可能是:

  • 到平台设施的硬件接口(例如芯片组中内置的中断控制器)
  • 各种类型设备的硬件接口
  • 抽象设备驱动接口
  • 内核的 API
  • 一种“运行时”语言(例如,可能是一个或多个共享库,也可能是像 Java 虚拟机这样的虚拟机)
  • 工具(例如编译器、链接器)生成的程序
  • 开发者的源代码

在所有这些层面上,都有(有益的)谎言和诡计。您可能认为您将变量 X 设置为值 123,但编译器决定优化代码并执行其他操作。您可能认为您收到了来自操作系统的通知,但该通知实际上来自语言的运行时并且操作系统从未发送过它。您可能会认为通知重新启动了一个线程,但线程是某人(可能是编译器,可能是运行时,可能是内核)的一个大谎言。

弄清楚异步通知如何工作的确切机制以及它在所有不同层的实际情况;您需要了解有关特定场景的更多信息(哪个编译器编译哪个版本的哪个语言的哪个通知,哪个设置在哪个架构/硬件之上的哪个操作系统上运行)。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2013-09-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-03-04
    • 1970-01-01
    相关资源
    最近更新 更多