Question

这只是一个技术问题，可以提高我对操作系统架构的理解。

我理解在执行Application.Run（）方法时，会创建一个带有消息泵的新表单。从MSDN和其他在线文章中，我了解其线程安全性，甚至理解像HAL层，核心OS服务和层次结构顶部的应用程序等Windows操作系统组件都使用消息传递彼此之间进行通信。

此自定义仅适用于Windows，还是在Linux环境中也是如此？

这可以被视为信号量吗？或者信号量的定义和上下文只在多线程环境中有意义吗？

请建议。

谢谢，

Subbu

Answer 1

流程可以通过多种方式进行通信，称为IPC - 进程间通信。从历史原因来看，在类UNIX系统中，使用其他机制在进程之间进行通信而不是消息循环。 UNIX进程通常通过管道进行通信（可以将它们视为临时文件，只能在一个进程中写入并在另一个进程中读取），信号（代码抢占某些进程的实际执行）或处理返回值（类似于函数）返回）。还有很多其他的沟通方式（套接字，共享内存，文件），但这些是最常见的。

至于信号量：我不确定这些信息应该如何与消息传递相关，信号量对象旨在允许程序员创建关键的代码段。因为在UNIX中，即使在不同的进程（不仅是一个进程中的不同线程）之间也可以共享信号量，它们在任何多进程操作系统（几乎是当今的所有操作系统）中都是有意义的，即使没有线程支持也是如此。

嗯，信号量甚至可以用于原纤维 - 用户空间线程，它不像线程那样耗尽时间量，但可以手动控制另一个原纤维（例如当原纤维即将开始长时间阻塞时）从硬盘读取数据等操作，它可以请求数据，而不是阻止切换到另一个想要CPU的原纤维。

Answer 2

Unix系统有消息队列：

#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/msg.h>

int msgsnd(int msqid, const void *msgp, size_t msgsz, int msgflg);
ssize_t msgrcv(int msqid, void *msgp, size_t msgsz, long msgtyp, int msgflg);

比Windows消息使用得少，但操作方式非常相似。同样是一个非常相似的概念，Go language很好地实现了CSV（communicating sequential processes），这是一个很好的多任务范例，因为它不会受到指数复杂性增长的影响。我建议Unix系统程序员更多地使用消息队列。

Windows消息也有点类似于Unix信号，但Unix信号（通常）没有参数，数量非常有限（通常只有32，与数千条Windows消息相比），信号处理程序必须执行一个奇怪的悬浮环境，这使它们更不实用。尽管如此，信号在Unix编程中比消息队列更受欢迎。

关于信号量

您应该首先尝试使用互斥量，而不是使用信号量（具有附加的计数器），互斥量更轻，可用于同步同一进程内的线程。

Windows消息泵

2 个答案:

关于信号量