【问题标题】:Does printing to the screen cause a switch to kernel mode and running OS code in Unix?打印到屏幕会导致切换到内核模式并在 Unix 中运行 OS 代码吗?
【发布时间】:2011-09-22 12:24:02
【问题描述】:

我正在学习测试是操作系统(unix 是我们的模型)。 我有以下问题:

以下哪两项不会导致用户程序停止并切换到操作系统代码?

A.程序发现错误并且是 将其打印到屏幕上。

B.程序分配的内存 稍后会从磁盘中读取。

好吧,我有答案,但是,我不确定它们有多好。 他们说答案是 B。 但是,B 是当用户使用malloc 时,这是一个系统调用吗?分配内存不通过操作系统? 为什么打印到屏幕需要操作系统?

感谢您的帮助

【问题讨论】:

    标签: unix operating-system


    【解决方案1】:

    malloc 不是系统调用。这只是一个函数。

    当您调用malloc 时,它会检查它(内部)是否有足够的内存给您。如果是,它只返回地址 - 无需陷入内核模式。如果没有,它会询问操作系统(实际上是系统调用)。

    根据完成打印的方式,这也可能会或可能不会引发系统调用。例如,如果您使用stdio,则打印是用户缓冲的。这意味着printf 意味着复制到一些stdio 缓冲区而没有任何实际的I/O。 然而,如果printf 决定刷新,那么确实必须执行系统调用。

    【讨论】:

    • 我读到malloc 是一个库例程,它调用brk 系统调用来分配内存。不是一直都是真的吗?
    • @logic_max 不,并非总是如此。
    【解决方案2】:

    printf()malloc() 调用调用 C 运行时库 (libc)。 C 运行时库是内核之上的一层,最终可能会根据情况调用内核。

    内核通过brk()(扩展/收缩数据段)和mmap()(将内存页映射到进程虚拟地址空间)提供了一些原始的内存分配。 Libc 的malloc() 内部管理它从内核获得的内存,并试图最小化系统调用(除其他外,它还试图避免过多的碎片,并试图在多线程程序上具有良好的性能,所以必须做一些妥协)。

    stdio 输入/输出(通过*printf()/*scanf())被缓冲,并最终调用内核的write()/read() 系统调用。默认情况下,stderr(错误流)是无缓冲或行缓冲的(ISO C §7.19.3 ¶7),因此可以立即看到错误。 stdinstdout 是行缓冲或非缓冲的,除非可以确定它们没有连接到交互式设备,以便输入的交互式提示正常工作。 stdinstdout 如果引用磁盘文件或其他非交互式流,则可以进行完全缓冲(块缓冲)。

    这意味着默认情况下,保证在您输出'\n'(newline) 字符后立即看到错误输出(除非您使用setbuf()/setvbuf())。正常输出还需要连接到终端或其他交互设备以提供该保证。

    【讨论】:

      【解决方案3】:

      在 A 中,用户程序负责检测错误并决定如何提供该信息。然而,在大多数情况下,实际将字符渲染到显示设备或终端会涉及到操作系统调用。

      在 B 中,操作系统当然负责内存管理,并且分配可能在某些时候向操作系统请求内存,或者操作系统可能必须提供磁盘交换。

      所以答案可能严格来说都不是。但是 A 需要系统调用,而 B 可能需要系统调用。

      【讨论】:

      • @cnicutar: stderr 默认为无缓冲/行缓冲。
      • @ninjalj 该操作在原始问题中没有提到stderr;默认!= 总是。所以“will”就是“might”。
      • @ninjalj 我什么都不做,并解释所有的含义。
      • @cnicutar;我不明白你的意思;如果没有进行刷新,则不显示任何内容,并且问题明确表示“打印到屏幕”,因此可以假设已采取措施导致这种情况发生。
      • @Clifford 为什么假设什么?他没有说“信息已显示”或“信息中的光子正在撞击我的视网膜”。问题说:“打印”。好的,printf("Danger!"); _exit(1);。 printf 会调用多少个系统调用?
      【解决方案4】:

      答案是 A。在检测到错误后处理错误由编程语言运行时和用户空间应用程序处理。另一方面,mmap 文件需要进入内核模式来分配必要的页面并排队任何磁盘 IO。所以 B 绝对不是正确的选择。

      【讨论】:

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