09-19-2017 11:31 AM
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
Solved! Go to Solution.
09-20-2017 03:45 PM
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
09-21-2017 09:59 AM
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.
09-22-2017 04:22 PM
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.~
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.