Measurement Studio for .NET Languages

cancel
Showing results for 
Search instead for 
Did you mean: 

Task name conflicts with an existing task name.

Solved!
Go to solution

When I am testing my code the temperature displays correctly and everything works as I expected. Then, after testing when I go back into code, specifically XAML, I get an error from my Thermocouple class saying that a task name conflicts with an existing task name. I can close the error and go about my business as usual. But it bothers me because I finalize that class when the program closes and call the Dispose method on the task.

 

        ~Thermocouple()
        {
            if(tempReader!=null)
                tempReader = null;
            if(tempChannel!=null)
                tempChannel=null;
            if(tempTask!=null)
                tempTask.Dispose();
        }

Is there something I should be doing to avoid this? It doesn't seem to affect anything, but if the task is still present after the program shuts down, then it could potentially be a problem. Suppose the user closes the program and immediately restarts it? Will there be a conflict?

 

Thanks

0 Kudos
Message 1 of 4
(2,611 Views)

Hi ScottinTexas,

 

Calling the Dispose method on the task should be all we need to do to clear it. Have you confirmed that this code is being executed in your application?

 

Also, would you be able to provide a little more information on when this error occurs? Is it just when you go back into the development environment to code after running the application? 

 

ShaneK

0 Kudos
Message 2 of 4
(2,577 Views)

Thank you for your response, Shane. Yes this only happens when I exit the program and go back into the XAML. I suppose it happens then because of the binding to the temperature.

 

Also, I did step through the destructor and confirmed that Dispose was executed. Am I right that Dispose simply flags the object as disposable so when Garbage Collection happens it can take the object? Dispose does not actually dispose of the object does it? If that is the case, then garbage collection is slow and hasn't happened yet. Then the task is still in memory.

 

Anyway, this is a nuisance problem. It does not occur in the release version.

0 Kudos
Message 3 of 4
(2,571 Views)
Solution
Accepted by topic author ScottinTexas

Am I right that Dispose simply flags the object as disposable so when Garbage Collection happens it can take the object? Dispose does not actually dispose of the object does it?

It sounds like you have the concepts reversed:

  • IDisposable is a managed interface that allows unmanaged resources to be reclaimed eagerly, in a deterministic way.
  • Finalizers (declared using ~ destructor syntax) are a non-deterministic method lazily invoked by the garbage collector as a last resort to finish object cleanup.

In most cases, a finalizer should only be used if you directly access unmanaged resources (i.e. handles or IntPtr references). If you only access managed types (like a task), then there is no need to define your own finalizer (the managed object will handle that). However, you may want to define your own Dispose method (see the "Explicit Release of Resources" section).

 

I expect the problem you are seeing is because the garbage collector does not always happen to invoke the ~Thermocouple finalizer by the time you get back to code. It would be better to dispose the Thermocouple immediately when the window closes, rather than waiting for the garbage collector to come along and invoke the finalizer.

~ Paul H
Message 4 of 4
(2,561 Views)