跨进程互斥体的使用
操作系统：Windows 语言：C/C++
设计要求跨进程及其子进程使用互斥变量。 如果我在一个进程中创建互斥锁，我必须在另一进程中打开互斥锁以检查关键部分的可用性。 要打开互斥体，我需要知道在父进程中创建的互斥体的名称。假设，如果我将互斥体保留为我的应用程序名称。我可以知道互斥锁的名称，因为它是固定的。但是，如果我并行加载应用程序的第二个实例，则会出现混乱。
以下是更好的主意吗？ 我有一个想法，将父进程中的互斥体命名为进程id。所以现在我需要从子进程/孙进程中获取父进程的进程ID以打开互斥体。 我想没有直接的方法可以从孙子进程中获取父进程ID。所以我必须在每个创建进程 api（在 lpenvironment parm 中）中传递进程 id。
任何人都可以建议一个简单的方法，因为互斥体是最常用的......我是新手。
OS: Windows Language: C/C++
The design demands to use a mutex variable across process and its sub processes.
If I create mutex in one process, I have to open the mutex in another processs to check the critical section's availablity.
To open the mutex, I need to know the name of the mutex created in parent process. Suppose, If I keep the mutex as my application name. I could know the name of the mutex, as it is fixed. However, If I load the second instance of my application parallel, there would be a confusion.
Can the following be the better idea?
I have an idea to name the mutex in the parent process as the process id. So now I need to fetch the Parent's process ID from the child process/grand child process to open the mutex.
I guess there are no direct ways to fetch parent process id from the grand child process. So I have to pass on the process id in every create process api(in lpenvironment parm).
Can anyone suggest a simple method, as mutexes are most commonly used.... I am a newbie.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
主要想法很好，但您也许可以进行一些实施调整。
其一，如果您的应用程序涉及多个进程协作，那么生成子进程的主“控制器”进程可以轻松地通过命令行参数传递其 PID。如果子进程也生成自己的子进程，它们可以通过相同的机制传输 PID。
进一步考虑这个想法，您还可以完全跳过 PID，并通过命令行参数将互斥体名称本身传递给子进程。这种方法的优点是父进程和子进程不需要同时包含从 PID 派生互斥体名称的代码。通过传递互斥体名称本身，您可以将子进程从必须知道它是如何生成的过程中分离出来。许多主流应用程序都使用这种方法，例如 Google Chrome。
最后，您可以通过向互斥体名称添加随机字符串（也许是 GUID？）来做得更好。我不相信任何人都会用相同的名称命名自己的全局同步对象，但一些额外的预防措施不会有什么坏处。
The main idea is fine, but you can maybe make some implementation tweaks.
For one, if your application involves multiple processes cooperating, then the main "controller" process which spawns sub-processes can easily pass its PID via a command line argument. If sub-processes spawn their own children as well, they can transfer the PID via the same mechanism.
Taking this idea further, you can also skip the PID entirely and pass the mutex name itself via command line argument to child processes. This approach has the advantage that the parent and child processes do not need to both include code that derives the mutex name from the PID. By passing the mutex name itself you decouple child processes from having to know how it is produced. This approach is used by many mainstream apps, e.g. Google Chrome.
And finally, you can maybe do better by adding a random string (a GUID maybe?) to the mutex name. I don't believe anyone will name their own global synchronization object with the same name, but some extra precautions won't hurt.
据我了解，您建议使用进程 ID (PID) 作为命名应用程序及其子进程要使用的互斥体的基础。这样，它们将拥有自己的互斥体名称，不会与应用程序的第二个实例使用的互斥体名称冲突。
这看起来有效，但句柄比 PID 更可靠，因为 PID 可以回收。使用句柄的方法（将它们传递给子进程，类似于您建议的方法）在 此 StackOverflow 线程。
我认为将需要共享的信息传递给子进程是正确的方法。 Windows 具有控制台进程及其子进程的进度组的概念，但这实际上是为了能够将所有进程作为一个组发出信号而设计的，而不是为了在组之间共享信息。
还有作业对象用于管理属于同一作业的一组进程，但同样，这是为管理一组进程而设计的，而不是为了在组中的进程之间共享信息。
As I understand it, you propose to use a process ID (PID) as the basis for naming a mutex to be used by your application and its subprocesses. This way, they will have their own mutex name that will not clash with the mutex name used by a second instance of your application.
This appears valid, but handles would be reliable than PIDs, because PIDs can get recycled. The method of using handles (passing them to child processes, similar to what you sugggest) is discussed on this StackOverflow thread.
I think passing the information you need to share to child processes is the way to go. Windows has the concepts for progress groups for a console process and its child processes, but this is really designed for being able to signal all the processes as a group -- not for sharing information among the group.
And there are also job objects for managing a group of processes that belong to a common job, but again, this is designed for managing a group of processes, not for information sharing between the processes in the group.
如果我解释“进程及其子进程”以及“子进程/孙进程”这一措辞，则情况是您有一个单父进程，它启动一个或多个子进程（或者，子进程）发射孙子）。或者，这些的任意组合，但无论哪种方式，我们谈论的每个进程都使用由父进程创建的相同互斥体。
如果这个假设是正确的，为什么不直接使用一些令人尴尬的简单内容，例如：
如果你想知道这个来自哪里，我用这句话生成它：
用你的名字、当前日期或任何随机的内容替换“一些文本”此时此刻，言语就在你的脑海里。系统上的任何其他应用程序具有相同互斥体名称的可能性几乎为零。
If I interprete the wording "a process and its sub-processes" as well as "child/grandchild", the situation is that you have a single parent process that launches one or several children (or, children launching grandchildren). Or, any combination of these, but either way, every process we talk about using the same mutex that is created by the parent.
If that assumption is correct, why not just use something embarrassingly simple as:
In case you wonder where this one came from, I generated it with this one-liner:
Replace 'some text' with your name, the current date, or whatever random words are at your mind at this very moment. The chances that any other application on your system will ever have the same mutex name is practically zero.