问题标签 [multiple-processes]

我有一个应用程序，其中有 3 个不同的进程需要在 Windows 上以 3 种不同的语言同时运行：

• 与传感器阵列接口的“数据收集”过程。传感器阵列的开发人员非常友好地向我们提供了他们的 C# 源代码，我可以对其进行修改。这应该生成原始数据并将其推入共享内存
• “后处理”过程。这是使用 CUDA 尽可能快地完成处理的 C++ 代码。这应该是获取原始数据，将其移动到 GPU，然后从 GPU 获取结果并将其传达给——
• 用 Matlab 编写的反馈控制器，它获取后处理的结果并使用它来决定如何控制机械系统。

我已经完成了关于并行编程的课程，但是这些课程都在 Linux 中工作，我使用了mmap.h多个进程之间的协调。这对我来说很有意义——您要求操作系统将虚拟内存中的一个页面映射到共享物理内存地址，然后操作系统会为您提供一些共享内存。

谷歌搜索，似乎在 Windows 中的进程之间设置共享内存的首选方法（事实上，在 Matlab 中这样做的唯一“简单”方法）是使用内存映射文件，但这对我来说似乎完全是疯狂的。如果我理解正确，内存映射文件会占用一些磁盘空间并将其映射到物理地址空间，然后将其映射到访问同一内存映射文件的任何进程的虚拟地址空间。

这似乎比仅让多个进程将其虚拟地址空间中的页面映射到同一物理内存所需的复杂度高出三倍。我觉得我不应该为我想要完成的事情做任何与磁盘 I/O 远程相关的事情，特别是因为性能对我来说是一个大问题（理想情况下我应该能够每秒处理 1000 组数据，尽管这不是硬性限制）。这真的是协调我的流程的正确方法吗？

假设有一个系统有 8 个内核，每个内核有 1 个线程和 32 GB 的 RAM。我想在单个进程中运行 case 1 -> 4 个线程（线程是独立的，因此不需要同步）和 case 2 -> 4 个进程，每个进程都有单个线程。撇开内存消耗和创建它们所花费的时间不谈，在 Linux 系统上的上述情况下，执行时间是否会有显着差异？为什么/为什么不？大多数操作系统书籍都涉及单核和单线程系统。

我有 3 个单独运行的 Spring Boot - Camel 应用程序。我需要链接这些进程，比如在进程 A 完成时它应该启动进程 B，然后一旦进程 B 完成，它应该继续进程 C。如果任何进程在两者之间失败，进程链应该重试失败的一个，然后继续执行到下一个。此外，在流程 A 中，如果路线中的任何步骤出现任何故障，那么我还需要重试并从中间步骤开始。任何人都可以帮助我实现这个场景吗？

抱歉，代码太长了，我试图让它尽可能简单但可重现。

简而言之，这个 python 脚本启动了四个进程，将数字随机分配到列表中。然后，将结果添加到multiprocessing.Queue().

所有进程都运行这print "after the queue.put"条线。但是，它并没有达到要求print "the end"。很奇怪，如果我将arangefrom更改10001为1001，它就会结束。怎么了？

我的大学项目有问题。我与产品和仓库中每种产品的数量有一个共享变量。在“I”秒的时间间隔内，随机产品中有 Q 的供应。它向进程“仓库”发送一条消息，该消息将该数量添加到共享内存中。它在中央打印产品及其数量。但是，在中央，数量始终相同，并且不会增加。这是代码：

Q、S、产品和数量等一些变量取自文本文件。所有这一切都完美无缺，只是共享内存没有在中央更新，我没有看到有什么问题。任何帮助，将不胜感激。Soma 代码可能是错误的，因为我已从原始文件中获取它并尝试将其改编为这篇文章。如果您有任何疑问，请随时提问。

SIGCHLD处理和功能之间的关系是什么sleep？

因为当我从上面执行代码时，它会打印：

但是执行中的功能没有影响sleep。这里有什么特殊性吗？

Say you have a config.py which inside has

so config.settings is a dictionary.

in one script foo.py you have:

and in another script bar.py you have

How would you keep the printed value in bar.py up to date with the new value after running foo.py at any time without the obvious reading the file again seeing as the while loop in bar.py needs to be as quick as possible!

I currently run these on seperate bash threads i.e:

But I could run bar in a thread if that is possible?

我知道 Process 和 Thread 是完全不同的东西。但我有一个关于他们的问题。既然 Python 有 GIL，那么单线程和单进程处理任务之间有什么性能差异吗？

编辑1：我认为需要大量CPU计算的任务没有什么不同。但是如果是 Asynchronous_I/O 任务，这个进程还是有优势的，因为它可以多线程。

我正在阅读关于 Linux x86-64 系统的信号/ECF 的教科书章节（CS：APP，第 3 版，第 8 章，第 781 页），并遇到了这个问题：

sigsuspend 函数暂时用掩码替换当前的阻塞集，然后暂停进程，直到接收到一个信号，该信号的动作是运行处理程序或终止进程。如果该操作要终止，则该过程终止而不从 sigsuspend 返回。如果操作是运行一个处理程序，则 sigsuspend 在处理程序返回后返回，将阻塞集恢复到调用 sigsuspend 时的状态。

sigsuspend 函数等效于以下的原子（不可中断）版本：

据我了解，sigprocmask(SIG_BLOCK, &mask, &prev)应该导致阻塞集与掩码进行或运算，即将掩码中的信号添加到已经在阻塞集中的信号。但是代码正上方的文本（以及我查找的 sigsuspend 的手册页）说 sigsuspend “暂时用掩码替换当前的阻塞集”。在我看来，这听起来更像sigprocmask(SIG_SETMASK, &mask, &prev)是阻塞集被设置为等于掩码中的信号。

那么为什么sigsuspend(&mask)等同于上面的代码（第 1-3 行）而不是下面的代码（第 4-6 行）？我的直觉和/或对 signal.h 函数的理解哪里出错了？

如果我不清楚，让我问一个具体的问题（它可能更好地解释我的直觉）。假设当前阻塞集编码 SIGCHLD，sigset_t 掩码编码 SIGINT。我打电话sigsuspend(&mask). 无论哪种代码解释是正确的（第 1-3 行或第 4-6 行），在调用 sigsuspend 之后传递的 SIGINT 信号将被阻止/不会唤醒进程。但是，如果在调用 sigsuspend 之后立即传递 SIGCHLD 信号怎么办？进程会唤醒/接收信号吗？我的直觉说第 1-3 行会阻止 SIGCHLD，而第 4-6 行不会，所以很明显第 1-3 行和第 4-6 行不等价。但是我的直觉也说 sigsuspend 不应该阻止 SIGCHLD 因为它不在掩码中，所以第 4-6 行是正确的，如果在这种情况下第 4-6 行等效于 sigsuspend，则 sigsuspend 不能等效于第 1 行- 3. 我的直觉/理解哪里出了问题？

我正在尝试了解阻塞和解除阻塞信号的工作原理，并且我正在尝试理解以下代码。具体来说，我正在查看第 28 行（在代码中注释）int a = sigprocmask(SIG_UNBLOCK, &mask, NULL);：，也就是信号在孩子中畅通的地方。

我从中得到代码的教科书说代码使用信号阻塞来确保程序printf("adding %d\n", pid);在其删除功能（简化为）之前执行其添加功能（简化为printf("deleting %d\n", pid);）。这对我来说很有意义；通过阻塞SIGCHLD信号，然后在执行 add 函数后解除阻塞，我们确保在执行 add 函数之前不会调用处理程序。但是，我们为什么要解锁孩子的信号呢？这不是通过立即解除阻塞来消除阻塞的全部意义，允许孩子在父添加之前删除吗？

但是，无论我是否注释掉了该行，输出（在代码之后描述）都是相同的，这意味着这显然不是发生的事情。教科书说：

SIGCHLD“注意孩子继承了父母的屏蔽集，所以在调用之前我们必须小心解锁孩子的信号execve。”

但在我看来，解除阻塞仍会导致调用处理程序。这条线具体是做什么的？

输出：