Re: Did GC eat my mutex? Why did Mutex need to be static?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Willy Denoyette [MVP] (willy.denoyette_at_pandora.be)
Date: 04/23/04 

Date: Fri, 23 Apr 2004 12:44:34 +0200

Hmmm, How can the GC collect it when it's reference is not stored somewhere?
Did you actually look at the IL?

Not sure if you aren't confusing compiler with Jitter, but this has nothing
to do with the compiler and compiler optimizations, it's actually the Jitter
that 'sees' that the reference is not longer needed when Application.Run
returns, so it sets the reference to null when calling Application run, so
it's a runtime optimization.
When running in the debugger, the Jitter doesn't perform any kind of
"optimizations', as such the mutex is maintained until main goes out of
scope.

 Willy.

"BMermuys" <someone@someone.com> wrote in message
news:eBC8hYMKEHA.2776@TK2MSFTNGP12.phx.gbl...
> Hi,
>
> The garbage collector only collects objects which don't have at least one
> valid reference. In your case there seems to be a valid reference because
> Application.Run doens't return until the app quits and so mutex is a valid
> though local variable.
>
> The "problem" is with the compiler, it is the compiler that can see that
> you
> don't use the created object. So in release build when optimizing, it
> sees
> that mutex isn't used. Therefore there won't even be a local variable
> "mutex" in the release build (ilasm). It creates the mutex but it doesn't
> store its reference anywhere, which is the reason the gc collects it.
>
> Putting mutex.Close after Application.Run is a good solution to prevent
> the
> unwanted optimalization.
>
>
> HTH,
> greetings
>
>
> "Ed Sutton" <S_P_A_M_esutton@nomadics.com> wrote in message
> news:eMDuV6JKEHA.268@TK2MSFTNGP11.phx.gbl...
>> I use a mutex to disallow starting a second application instance. This
>> did not work in a release build until I made it static member of my
>> MainForm class.
>>
>> In a debug build, first instance got ownership, second did not and
>> terminated. In a release build, the second instance *also* got
>> ownership. I "fixed" it by making the mutex a static member of my
>> MainForm class.
>>
>> Did the garbage collector eat my mutex because it is not referenced
>> again after Application.Run is called?
>>
>> I could not reproduce this on a new simple WinForm project; I tried
>> making all the project setting the same. Here's the code that did not
>> work in release build.
>>
>> [STAThread]
>> static void Main()
>> {
>> try
>> {
>> bool firstInstance = false;
>> string safeName = Application.UserAppDataPath.Replace(@"\","_");
>> Mutex mutex = new Mutex(true, safeName, out firstInstance);
>> if(false == firstInstance)
>> {
>> return;
>> }
>> Application.Run(new FrmMain());
>> }
>> catch(Exception ex)
>> {
>> Err.Show(ex, "Caught an unexpected exception in FrmMain");
>> }
>> }
>
>

Relevant Pages

  • Unexpected release of named mutex
    ... I have a mutex that releases while I am still holding a reference to ... Dim singleInstance As Threading.Mutex = Nothing ... Application.ProductName & ".SingleInstance", goodToGo) ... Silly me, thinking that I could keep a reference to an object by, uh, ...
    (microsoft.public.dotnet.framework)
  • Re: [PATCH RFD] alternative kobject release wait mechanism
    ... There is no reason to hold reference to it. ... you grab the mutex excluding its removal and verified it's still there. ... It also wakes up all threads that are blocked trying to lock the ...
    (Linux-Kernel)
  • Re: WaitForSingleObject() will not deadlock
    ... You keep talking about needing to know the reference count. ... algorithm that uses a recursive mutex that cares in the slightest what the reference count ... attempts to lock appears to be isomorphic to a recursive lock, ... cycle detection until you reach the end of the list, ...
    (microsoft.public.vc.mfc)
  • Re: Library design for canceling a running operation?
    ... The main part of the public api is very similar to normal file I/O: ... cancel a running operation. ... thread that's performing the operation has a reference. ... The operation object contains a mutex, condition variable, and any ...
    (comp.programming.threads)
  • Re: [PATCH RFD] alternative kobject release wait mechanism
    ... Tejun Heo wrote: ... Here's an example where immediate-detach cannot be implemented. ... There is no reason to hold reference to it. ... I probably have over simplified it but using both mutex and reference ...
    (Linux-Kernel)