本文介绍了进程退出时自动释放信号量的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用Semaphore限制我的应用程序可以运行的并发实例的数量。

I am using Semaphore to limit the number of concurrent instances my application can run.

有多种方法可以终止进程。可以创建信号量使其在进程退出时自动释放吗?

There are many ways a process can terminate. Can the Semaphore be created so it automatically releases upon process exit?

编辑:

我想要一些魔术来自动清除退出或崩溃时拥有它的进程的升起状态。只是为了确保已清除,无论如何。

I would like some magic to automatically clean up the semaphore 'raised' state for the process owning it upon exit or crash. Just to be sure that it is cleared, no matter what.

更多:

我正在寻找任何考虑到以下因素,它是可行的选择:

I am looking for any viable option for it, considering:


  • 不需要外部应用程序来保留受保护应用程序的每个实例将是一个很好的选择

  • 它不必是信号量-任何具有COUNTER并且在所有者进程死亡时自动释放的同步对象都可以,即使它作弊

  • 我正在使用.NET 2.0,无法在该项目上升级到新版本,但可以使用c / c ++和互操作来利用某些东西

推荐答案

您可以插入事件,以执行任何清理操作,例如释放信号量。

You can hook into the AppDomain.ProcessExit event to perform any cleanup operations like releasing the semaphore.

通常,命名信号量旨在协调跨流程分配资源,而无需考虑特定的流程生命周期。 .NET中的信号量由,并且MSDN说:

Generally, named semaphores are designed to coordinate resources across processes without taking particular process life-time into account. Semaphores in .NET are backed by native Windows semaphore objects, and the MSDN says:

因此,正确的方法是在进程终止之前进行显式处理。

Hence the right approach is explicit handling before process termination.

更新-其他要考虑的选项:

Update — Other options to consider:


  1. 如果在 AppDomain.ProcessExit 事件中手动处理紧急发布不可行,请考虑创建一个 IDisposable 包装器,该包装器将在其构造函数中获取信号并通过 Dispose 方法释放该信号。

  2. 另一个问题是:在这种情况下,信号量是否是正确的同步对象?一个简单的(命名)互斥体不能更好地工作吗?

  1. In case it's not feasible to handle "emergency" release manually in the AppDomain.ProcessExit event, consider creating an IDisposable wrapper that would acquire the semaphore in its constructor and release it in the Dispose method.
  2. Another question is: is a Semaphore the right synchronization object for this case? Wouldn't a simple (named) mutex work better?






更新-如果应用程序崩溃或被强制终止(例如通过任务管理器), ProcessExit 将没有机会得到处理。因此,可能无法正确完成/处置/处理在多个进程之间共享的任何非托管资源。有关更多信息,请参见详细信息。


Update — In case of an application crash or forced termination (i.e. via Task Manager) ProcessExit won't have a chance to be handled. Hence any unmanaged resources shared between multiple processes may not be finalized / disposed / handled correctly. See this article for further details.

可行的选择可能是。命名管道的优点是,一旦创建过程终止,它们便会退出。根据MSDN:

A viable option may be creating a named pipe. The advantage of named pipes is they cease to exit once the creating process is terminated. According to MSDN:

有两个选项限制管道实例的数量:

There are two options to limit the number of pipe instances:


  1. 仅一个实例:通过指定 FILE_FLAG_FIRST_PIPE_INSTANCE dwOpenMode 参数中的>标志可以禁止创建管道的多个实例。然后,尝试创建管道的第二个进程将收到错误。

  2. 更多实例:通过在 nMaxInstances 论点。当允许 N 时, N + 1 st进程将收到错误。

  1. Just one instance: By specifying the FILE_FLAG_FIRST_PIPE_INSTANCE flag in the dwOpenMode argument it is possible to prohibit creation of multiple instances of the pipe. Then, the second process attempting to create the pipe will receive an error.
  2. More instances: By specifying the number of allowed instances in the nMaxInstances argument. When N are allowed, the N+1st process will receive an error.

这篇关于进程退出时自动释放信号量的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

05-28 12:09
查看更多