Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>If you're really trying to do an inter-process lock, as the name implies, you will want a way to detect if the Mutex has actually been acquired anyway, correct? I'm not sure how your code that uses your <code>InterProcessLock</code> would be ensured to be locked if there was no <code>IsAcquired</code> property. (Also, to protect against programmers who accidentally call Dispose twice, I'd set the <code>IsAcquired</code> to <code>false</code> in your <code>Dispose</code> method.)</p> <p>I've implemented the same thing myself (because I much prefer the using block to a try-finally just to release the mutex) and instead threw an exception when the timeout was exceeded, which, if I'm remembering the project correctly, did not call the Dispose method. </p> <p><b>Edit:</b> Added benefit of throwing the exception in the constructor: your critical section is also completely avoided, and you can perform error handling in the <code>catch</code> block, which could include the same method call your critical section had, anyway, though I personally would consider that a bad practice.</p> <p>Upon further reflection, rather than using <code>try ... catch</code> as specified in another answer, you could use the following on your dispose:</p> <pre><code>public void Dispose() { if (IsAcquired) { lock (mutex) { mutex.ReleaseMutex(); IsAcquired = false; } } } </code></pre> <p>It feels a little ironic to <code>lock</code> a mutex, but there you have it. While I totally agree that you shouldn't rely on Dispose being called because of the documentation with the IDisposable interface, I think it is incredibly convenient to have an inter-process critical section indicated by a <code>using() { }</code> block.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload