Hi
When i use following code:
myManualResetEvent.Dispose();
Compiler gives this error:
'System.Threading.WaitHandle.Dispose(bool)' is inaccessible due to its protection level.
howevr following line works fine:
((IDisposable)myManualResetEvent).Dispose();
is it the correct way to dispose or at runtime it might crash in some scenerios.
Thanks.
The designers of the .NET Base Class Library decided to implement the Dispose method using explicit interface implementation:
private void IDisposable.Dispose() { ... }
The Dispose method is private and the only way to call it is to cast the object to IDisposable as you have discovered.
The reason this is done is to customize the name of the Dispose method into something that better describes how the object is disposed. For a ManualResetEvent the customized method is the Close method.
To dispose a ManualResetEvent you have two good options. Using IDisposable:
using (var myManualResetEvent = new ManualResetEvent(false)) {
...
// IDisposable.Dispose() will be called when exiting the block.
}
or calling Close:
var myManualResetEvent = new ManualResetEvent(false);
...
// This will dispose the object.
myManualResetEvent.Close();
You can read more in the section Customizing a Dispose Method Name in the design guideline Implementing Finalize and Dispose to Clean Up Unmanaged Resources on MSDN:
Occasionally a domain-specific name is more appropriate than Dispose. For example, a file encapsulation might want to use the method name Close. In this case, implement Dispose privately and create a public Close method that calls Dispose.
WaitHandle.Close
This method is the public version of
the IDisposable.Dispose method
implemented to support the IDisposable
interface.
According to the documentation, WaitHandle.Dispose() and WaitHandle.Close() are equivalent. Dispose exists to allow closing though the IDisposable interface. For manually closing a WaitHandle (such as a ManualResetEvent), you can simply use Close directly instead of Dispose:
WaitHandle.Close
[...]
This method is the public version of the IDisposable.Dispose method implemented to support the IDisposable interface.
Related
Is Close() same as Dispose() or using statement. Is it necessary to call using statement even if Close is called?.
I know before disposing of an object, close should be called, so we close the resource and may it available to Dispose.
https://msdn.microsoft.com/en-us/library/aa355056(v=vs.110).aspx
says Close is same as Dispose.
Is Close() same as Using statement?
No it is not.
Should you call Close() after a using?
No, it will break due to access to the disposed object.
Should I call Close() before exiting the using block?
It's complicated. If the IDisposable interface is implemented correctly: no. Otherwise: possibly.
Close() has no relation to IDisposable interface, see: https://msdn.microsoft.com/en-us/library/system.idisposable(v=vs.110).aspx
using only applies to IDisposable inherited objects, see: https://msdn.microsoft.com/en-us/library/yh598w02.aspx
Thus:
Close() and Dispose() may not considered to be related in any way.
When the IDisposable interface is correctly implemented, you may assume all clean-up necessary will be carried out. This implies an internal call to a Close() method would be carried out. This means that an explicit call to Close() should not be necessary.
The other way round; when a object is of type IDisposable and exposes a Close() method, a call to Close() will not be sufficient to properly dispose/clean-up the object. Dispose() must still be called, you can do this directly, or through the using statement.
You can also let the garbage-collector handle the Dispose() call for you (if its correctly implemented, see: Proper use of the IDisposable interface) But this is considered bad-practice, since you need to rely on a proper implementation and have no direct control over the GC timing.
Please note, a reason to implement a Close() function, is usually to give a developer a way to reuse the object. After calling Dispose() the object is considered to be marked for finalization and may not be used any more.
The using pattern is useful because it includes a try ... finally ... that will protect against exceptions...
If you do:
FileStream fs = null;
try
{
fs = File.OpenRead("MyFile.txt");
}
finally
{
if (fs != null)
{
fs.Close();
}
}
then in this case it would be nearly equivalent (because the Stream.Close() calls the Dispose(true))
BUT it is still "wrong"... You use using for IDisposable classes unless you have a very very good reason (there are some reasons for not doing it... Sometimes the lifetime of an object is very very difficult to track. In that case it is normally ok to no Dispose() it.).
The concept of a pattern is that it should become part of you... If you try to skirt from a pattern, then before or later you'll forget about it... And for what? For writing MORE lines that are MORE error-prone?
Not necessarily. I can write a class that has a Close and a Dispose method that aren't related.
class Foo : IDisposable
{
public void Close() { DoBar(); }
public void Dispose() { DoBaz(); }
}
The class RabbitMQ.Client.MessagePatterns.SimpleRpcServer implements IDisposable using an explicit interface implementation. The implementation is:
void IDisposable.Dispose()
{
Close();
}
That means that in order to call Dispose() on such a object, I first have to cast it to IDisposable. Why is the Dispose method declared in this way? Should I bother to call Dispose() on a SimpleRpcServer object? I could forget it and simply call Close(), I'm just asking because FxCop gave me a warning about it and I don't think I've seen explicit interface implementations before.
This implementation was present in some .NET classes. The confusion related to whether you needed to call Close, Dispose, or both, when really they all perform the same action.
An example of a class that implemented it this was is RegistryKey. In .NET 3.5 and before, it explicitly implemented the IDisposable interface. This encouraged you to either use it in a using or call the Close method.
In .NET 4.x and beyond, the IDisposable interface was implicitly implemented.
I believe Stream was implemented in a similar manner.
IDisposable came relatively late to the .NET Framework 1.0, as can be seen from this discusson from October 2000, and particularly the following extract:
First, we are discussing formalizing a design pattern that we already use
within the framework. All of our resource classes already support a method
called Dispose(). It is a public method that you can call at any time that
will release the resources contained by the object. Think of it kind of
like the c++ delete operator but it doesn't actually free the memory, it
just runs the destructor. We are considering making this an interface to
help codify the design pattern and facilitate some language support as
described below.
I believe (*) this is why many .NET 1.0 classes expose a Close method and only implement IDisposable explicitly. And I think this was considered to be a mistake, which is why in later versions of .NET it is more common to see IDisposable implemented implicitly. For example, a public Dispose method was added to the Stream class in .NET 2.0.
(*) my supposition, I don't have any inside knowledge.
It could be to maintain a common verb if the framework is provided in multiple languages where Dispose might not mean anything
Or it could be done because Dispose might not make as much sense if there is also an Open method since Close is a common opposing verb to Open.
For example, the ADO DbConnection classes all do this:
connection.Open();
conncetion.Close();
Alternativly, it could be that IDisposable was implemented after the product was already shipped and had an existing Close method and to maintain backwards compatibility Dispose was hidden by explicit implementation which Close then calls:
e.g.
// version 1
public class Thing
{
public void Close() { ... }
}
// version 2
public class Thing : IDisposable
{
public void Close() { ... }
void IDisposable.Dispose() { Close(); }
}
Say I have the following:
public abstract class ControlLimitBase : IDisposable
{
}
public abstract class UpperAlarmLimit : ControlLimitBase
{
}
public class CdsUpperAlarmLimit : UpperAlarmLimit
{
}
Two Questions:
1.
I'm a little confused on when my IDisposable members would actually get called. Would they get called when an instance of CdsUpperAlarmLimit goes out of scope?
2.
How would I handle disposing of objects created in the CdsUpperAlarmLimit class? Should this also derive from IDisposable?
Dispose() is never called automatically - it depends on how the code is actually used.
1.) Dispose() is called when you specifically call Dispose():
myAlarm.Dispose();
2.) Dispose() is called at the end of a using block using an instance of your type.
using(var myAlarm = new CdsUpperAlarmLimit())
{
}
The using block is syntactic sugar for a try/finally block with a call to Dispose() on the object "being used" in the finally block.
No, IDisposable won't be called just automatically. You'd normally call Dispose with a using statement, like this:
using (ControlLimitBase limit = new UpperAlarmLimit())
{
// Code using the limit
}
This is effectively a try/finally block, so Dispose will be called however you leave the block.
CdsUpperAlarmLimit already implements IDisposable indirectly. If you follow the normal pattern for implementing IDisposable in non-sealed classes, you'll override void Dispose(bool disposing) and dispose your composed resources there.
Note that the garbage collector does not call Dispose itself - although it can call a finalizer. You should rarely use a finalizer unless you have a direct handle on unmanaged resources though.
To be honest, I usually find it's worth trying to change the design to avoid needing to keep hold of unmanaged resources in classes - implementing IDisposable properly in the general case is frankly a pain. It's not so bad if your class is sealed (no need for the extra method; just implement the Dispose() method) - but it still means your clients need to be aware of it, so that they can use an appropriate using statement.
IDisposable has one member, Dispose().
This is called when you choose to call it. Most typically that's done for you by the framework with the using block syntactic sugar.
I'm a little confused on when my IDisposable members would actually get called. Would they get called when an instance of CdsUpperAlarmLimit goes out of scope?
No. Its get called when you use using construct as:
using(var inst = new CdsUpperAlarmLimit())
{
//...
}//<-------- here inst.Dispose() gets called.
But it doesn't get called if you write this:
{
var inst = new CdsUpperAlarmLimit();
//...
}//<-------- here inst.Dispose() does NOT get called.
However, you can write this as well:
var inst = new CdsUpperAlarmLimit();
using( inst )
{
//...
}//<-------- here inst.Dispose() gets called.
The best practice recommend when you implement Dispose() method in non sealed class you should have a virtual method for your derived classes to override.
Read more on Dispose pattern here http://www.codeproject.com/KB/cs/idisposable.aspx
when using an IDisposable object, it's always good to use it this way:
using(var disposable = new DisposableObject())
{
// do you stuff with disposable
}
After the using block has been run, the Dispose method will be called on the IDisposable object. Otherwise you would need to call Dispose manually.
When someone calls .Dispose on it.
No, it already implements it through inheritance.
IDisposable is implemented when you want to indicate that your resource has dependencies that must be explicitly unloaded and cleaned up. As such, IDisposable is never called automatically (like with Garbage Collection).
Generally, to handle IDisposables, you should wrap their usage in a using block
using(var x = new CdsUpperAlarmLimit()) { ... }
this compiles to:
CdsUpperAlarmLimit x = null;
try
{
x = new CdsUpperAlarmLimit();
...
}
finally
{
x.Dispose();
}
So, back to topic, if your type, CdsUpperAlarmLimit, is implementing IDisposable, it's saying to the world: "I have stuff that must be disposed". Common reasons for this would be:
CdsUpperAlarmLimit keeps some OTHER IDisposable resources (like FileStreams, ObjectContexts, Timers, etc.) and when CdsUpperAlarmLimit is done being used, it needs to make sure the FileStreams, ObjectContexts, Timers, etc. also get Dispose called.
CdsUpperAlarmLimit is using unmanaged resources or memory and must clean up when it's done or there will be a memory leak
From the resource clean-up perspective, why there are Response.Close() and Response.Dispose() and which one is more comprehensive (call the other one) ?
Where both methods are provided the implementation of Dispose should call Close. It is a good idea to use the using statement to ensure that Disposeand therefore Close is called, even if there is an exception.
In other words do this:
using (Response response = ...)
{
// ...
}
Not this:
Response response = ...;
// ...
response.Close(); // If there is an exception this might never get called!
One difference between closing and disposing an object is that when you dispose an object it usually is not possible to use the object any more (attempting to do so may cause an ObjectDisposedException to be thrown), but after calling Close it may be possible to still use the object.
Note that if you are talking about ASP.NET then you shouldn't normally call Close or Dispose on the Response object.
From the Design Guidelines for Developing Class Library on Implementing Finalize and Dispose to Clean Up Unmanaged Resources
Occasionally a domain-specific name is
more appropriate than Dispose. For
example, a file encapsulation might
want to use the method name Close. In
this case, implement Dispose privately
and create a public Close method that
calls Dispose. The following code
example illustrates this pattern. You
can replace Close with a method name
appropriate to your domain. This
example requires the System namespace.
/ Do not make this method virtual.
// A derived class should not be allowed
// to override this method.
public void Close()
{
// Call the Dispose method with no parameters.
Dispose();
}
Typically I've seen close whenever the resource can be opened or re-opened, since it gives nice symmetry to the method names.
Response.Close() closes the socket connection to a client.
Response.Dispose() is method which implements IDisposable interface and releases allocated resources.
I think Response.Close() is called from Response.Dispose() method.
For more detailed information you can use Reflector
using (FileStream fileStream = new FileStream(path))
{
// do something
}
Now I know the using pattern is an implementation of IDisposable, namely that a Try/Catch/Finally is set up and Dispose is called on the object. My question is how the Close method is handled.
MSDN says that it is not called, but I have read otherwise.
I know that the FileStream inherrits from Stream which is explained here. Now that says not to override Close() because it is called by Dispose().
So do some classes just call Close() in their Dispose() methods or does the using call Close()?
The using statement only knows about Dispose(), but Stream.Dispose calls Close(), as documented in MSDN:
Note that because of backward
compatibility requirements, this
method's implementation differs from
the recommended guidance for the
Dispose pattern. This method calls
Close, which then calls
Stream.Dispose(Boolean).
using calls Dispose() only. The Dispose() method might call Close() if that is how it is implemented.
Close() is not part of the IDisposable interface so using has no way to know whether it should be called or not. using will only call Dispose(), but intelligently designed objects will close themselves in the Dispose() method.
I don't think the using calls Close(), it would have no way of knowing that it should call that particular function. So it must be calling dispose, and that in turn is calling close.
In .Net classes Close() call Dispose(). You should do the same.