Develop Reference

Collection class and IDisposable interface

I've been reading about IDisposable interface lately (this topic was quite useful Proper use of the IDisposable interface) and also about usage of using statement (topic Uses of "using" in C#). Then I started wondering what if I should somehow free my own collection class from memory.
class User{
private string username {set;get;}
private string password {set;get;}
...
}
Should it implement IDisposable interface?
class User : IDisposable
{
...
public void Dispose()
{
this.Dispose();
}
}
so it could be freed from memory? Or does GC do it automaticly and I shouldn't even bother about it.
As far as I understand it's important to free unmanaged resources like DB connections and such but what about those collection classes. Since I use them quite frequently It really started to bug me.
tl;dr;
should I implement IDisposable on User class?
Kind Regards.
edit: thanks everyone for the replies!

Or does GC do it automaticly and I shouldn't even bother about it.
This. Unless you have unmanaged resources (either directly or by way of a reference to something else which is disposable), you almost certainly shouldn't implement IDisposable.
Your current implementation would just call itself:
public void Dispose()
{
this.Dispose();
}
... so assuming you don't really want to call this.Dispose(), what would you want to do when Dispose() is called? It's not like disposal causes garbage collection - so what action do you want to take? If the answer is "nothing" then you probably shouldn't be implementing IDisposable. (The exception here is if this is designed to be a base class and you're expecting some derived classes to require disposal... that's a more complex scenario.)

All unused resources will be Garbage collected eventually when the program unloads or after separate interval if the resources are no longer used.
Its a better practice to clean/dispose used resources(variables, objects) when you no longer wish to use them to free memory.

As said in the other answers, the only times you have to implement IDisposable is when you deal with unmanaged resources or class members that are IDisposable themselves (in this case you should dispose them in your own Dispose method).
Another scenario you might see is when people want to use the using { } syntactic sugar to automatically call some method at the end of the variable scope without using the try { } finally { } form.
I.e.:
public class MyObject : IDisposable
{
public void Foo()
{
}
public void Dispose()
{
// Something they want to call after the use of an instance of MyObject
}
}
...
using (var myObj = new MyObject())
{
myObj.Foo();
}
instead of
public class MyObject
{
public void Foo()
{
}
public void MethodToCallAfterUse()
{
// Something they want to call after the use of an instance of MyObject
}
}
var myObj = new MyObject();
try
{
myObj.Foo();
}
finally
{
myObj.MethodToCallAfterUse();
}

If an object asks an outside entity to "do something" (perform an action, reserve a resource, etc.) on its behalf until further notice, and that outside entity might continue to exist after the object requesting its services has ceased to be useful, then the object should ensure that the outside entity receives notice when its services are no longer required. The IDisposable resource exists as a standard means by which an object can say "I may be obligated to let outside entities know when I don't need their services; let me know when my services will no longer be needed, so I can satisfy my obligation to tell any outside entities that I no longer need their services."
In .NET, once no references to an object exist anywhere in the universe, the object itself will likewise cease to exist. If the only object which knows of an obligation to do perform some action ceases to exist without having performed the action, the action will not get performed. If an object has no obligations, however, having it simply cease to exist once there are no references is just fine.

IDisposable and ReaderWriterLockSlim

I have a class MyClass. This class have a field: public ReaderWriterLockSlim rw; (public for an easier example code). Many threads can read data from MyClass using rw.EnterReadLock etc.
Also I have implemented IDisposable interface:
private void Dispose (bool pDisposing)
{
{
if (pDisposing) // release managed resources
{
if (rw != null)
{
rwLockSlim.Dispose ();
rwLockSlim = null;
}
}
//--- release unmanaged resources
// some code...
isDisposed = true; // ...
}
}
Like you see, problem is when one thread is using MyClass when second thread call Dispose on myClass object. I cannot dispose ReaderWriterLockSlim because it will crash my application. So should I just remove that lines which releases managed resources? Anyway that ReaderWriterLockSlim will be collected by GC in near future, right? (but is this class resource expensive?).
Maybe I should add some lock(syncObject) in Dispose metod or something?
EDIT: also I deal with AllocHGlobal, so I need to wait, until all threads will stop reading/writing to myClass.
Different point of view:
public MyClass : IDisposable
{
public void EnterReadLock (); // calls rwLockSlim.EnterReadLock,
// if object is disposed throws Exception
public void ExitReadLock (); // same as above
public void Dispose (); // wait until all threads exit from locks,
// frees unamanged resources, mark class as disposed
}

This may not be the best answer, rather observations and some thoughts.
Can you simplify your code? I mean, other types shouldn't care if your type throws exceptions under specific concurrency conditions. How will you test this? Public lock object is evil. It must be private unless you want to spent months trying to figure out mysterious bugs.
If a dispose method is called, it means that no other objects should ever use this object. Which means you must ensure first that all threads finished operating on the object first, before calling a dispose method.
Suggestions
Make the lock private
Ensure all threads are finished, before calling to dispose
Add timeouts for safe behaviour
Consider using static lock object
ReaderWriterLockSlim is not resource expensive (to the point you should care about in your application)
If your class uses disposable resources, it is usually better to implement IDisposable and dispose members that need to be disposed.
Don't add any locks in the Dispose method, it shall be simple. This may introduce unpleasant bugs. Because if you forget to call a Dispose manually, it will be non-deterministically called by GC (through a finiliser, which you should add as well to call Dispose)
Correct approach would be to wait until all threads are done and dispose an object

Difference between these two Singleton implementations

I am learning how to implement some basic design patterns. Whilst learning the Singleton pattern I have noticed that there are two common implementations on the web:
// Possibly from: http://www.yoda.arachsys.com/csharp/singleton.html
// I cannot remember exact source, sorry :(
public sealed class Singleton
{
// Static members are 'eagerly initialized', that is,
// immediately when class is loaded for the first time.
// .NET guarantees thread safety for static initialization
private static readonly Singleton instance = new Singleton();
// Private constructor prevents instantiation from other classes
private Singleton() { }
// Explicit static constructor to tell C# compiler
// not to mark type as beforefieldinit
public static Singleton() { }
// Get the instance of the singleton
public static Singleton getInstance()
{
return instance;
}
}
and:
public class Singleton
{
// Static, VOLATILE variable to store single instance
private static volatile Singleton m_instance;
// Static synchronization root object, for locking
private static object m_syncRoot = new object();
// Property to retrieve the only instance of the Singleton
public static Singleton Instance
{
get
{
// Check that the instance is null
if (m_instance == null)
{
// Lock the object
lock (m_syncRoot)
{
// Check to make sure its null
if (m_instance == null)
{
m_instance = new Singleton();
}
}
}
// Return the non-null instance of Singleton
return m_instance;
}
}
}
In what scenario would you opt to have eagerly initialized vs lazy initialized?
Is the comment in the first example correct in saying that the initialization is thread safe? (I know it says it is, but it's the internet...)

I definitely would go with your first implementation...
the second seems questionable to me... if you need/want a lazy implementation you could use Lazy<T> for that - since it is part of the framework it feels much more comfortable..
BTW: There are even more ways to implement the Singleton pattern... here is an excellent article.

I'm not sure but it looks like you got those examples from here: http://www.yoda.arachsys.com/csharp/singleton.html
If not, read through it. There are a couple of thoughts on the two versions.
If you ask me personally: I would go for the 2nd solution if I needed to know if the singleton has already been initialized or not.
If you don't have to deal with multithreading, I would use an even simpler approach (see the "Bad Code" examples in the references link).

The first one is safe and lazy.
static constructors are guaranteed to be executed only once, and immediately before the first access to Instrance. If there is a static constructor(even if empty) then static field initializations are guaranteed to execute directly before the static constructor. If there is no static constructor, field initialization may occur earlier.
The second one is lazy, but I'm not sure if the double-lock pattern is valid like this. I suspect that it is broken, at least in the ECMA memory model.
Personally I'd avoid any Class.Instance singleton pattern in favour of IoC singletons in most situations.

1) that's entirely a design choice. Init up front or init when required.
2) Yes, it is thread safe as the CLR guarantees single threaded object initialisation. (static and instance)
EDIT
personally, in the first example, I make the Instance field public and dispense with the getter. Be interested to know if there is any reason that this is a bad idea?

It's a singleton so I'd go for option 1, unless it's a massive object that's not always even needed. But I probably would not make a singleton for something that's often not used at all.

Both implementations are fine, so it depends on what you need.
If performance is not an issue, use the eagerly created instance of the first one. Otherwise, use the second one, in which only the first access is synchronized.

Can I safely clean up after a readonly object field?

Let's say I have a class with a object field. When Dispose() is called I would like to clear the reference to that object. The private field can only be set once, so ideally I would like it to be readonly, but if it is readonly there is a compile time error when I try to release the reference to the object during Dispose(). Ideally I would like to have a safe dispose AND mark the _value field as readonly. Is this possible or even necessary?
public class Foo : IDisposable
{
public Foo(object value)
{
_value = value;
}
public object Value { get { return _value; } }
private readonly object _value;
public void Dispose()
{
//Cleanup here
_value = null // causes compile time error
}
}

That's not necessary, even if it were possible.
Dispose is typically intended to clean up unmanaged resources, although there can be exceptions to that rule (note the comments). However, in this situation, you should allow the garbage collector to do its job. It will run indeterminately once the objects are considered to have no active roots. Under normal circumstances, you do not need to take action to force it. Just write your code with objects in properly limited scope and you will be fine.

Setting the reference to null does not in fact do anything. The garbage collector will clean up the object when there are no longer any references to it, which in this case since you are doing this in the Dispose method presumably the instance of Foo is about to no longer have any references to it and the difference in timing is probably not meaningful. Typically you implement the Dispose pattern because your type has as a member a class that itself implements IDisposable (in this case the type is Object, which does not implement IDisposable), or you have unmanaged resources that you would like to release deterministically. You can find a description of the Dispose pattern here. Note that if you create a readonly member variable of a type that implements IDisposable you can call the Dispose method on that object inside your Dispose method:
public class SomeClass : IDisposable
{
private Boolean mDisposed;
private readonly MemoryStream mStream = new MemoryStream(); // Could be any class that implements IDisposable
public void Dispose() {
Dispose(true);
GC.SuppressFinalize(this);
}
protected void Dispose(Boolean disposing) {
if (disposing & !mDisposed) {
mStream.Dispose(); // Could and should call Dispose
mDisposed = true;
}
return;
}
}
This works because the readonly nature is on the reference to the object, not the object itself.

That is not necessary nor correct. Wanting to do what you ask in your question seems to indicate you are somewhere accessing a disposed object, and that is wrong.
Rather than try to do what you have asked, you should perhaps implement IsDisposed (which btw is part of the standard Dispose pattern) and check it first.
As others have noted, the Dispose pattern is intended for releasing unmanaged resources.

This is an older post, but I face the same question regularly because I unsubscribe from objects that I subscribed to.
I do this unsubscription during dispose because those objects live longer than this object, and the way delegates are implemented means that the publisher keeps the subscriber alive, not the other way around like we would think.
BUT, when you unsubscribe from the events, you have the natural tendency to want to clear the reference to the publisher too, which really isn't such a big deal. I suggest you keep the 'readonly' constraint because it makes the rules clearer and the code more robust while the object is still alive. If it means you sit with the reference after dispose, that is okay becuase the object is now collectible.

Who Disposes of an IDisposable public property?

If I have a SomeDisposableObject class which implements IDisposable:
class SomeDisposableObject : IDisposable
{
public void Dispose()
{
// Do some important disposal work.
}
}
And I have another class called AContainer, which has an instance of SomeDisposableObject as a public property:
class AContainer
{
SomeDisposableObject m_someObject = new SomeDisposableObject();
public SomeDisposableObject SomeObject
{
get { return m_someObject; }
set { m_someObject = value; }
}
}
Then FxCop will insist that AContainer is also made IDisposable.
Which is fine, but I can't see how I can safely call m_someObject.Dispose() from AContainer.Dispose(), as another class may still have a reference to the m_someObject instance.
What is the best way to avoid this scenario?
(Assume that other code relies on AContainer.SomeObject always having a non-null value, so simply moving the creation of the instance outside of the AContainer is not an option)
Edit: I'll expand with some example as I think some commenters are missing the issue. If I just implement a Dispose() method on AContainer which calls m_someObject.Dispose() then I am left with these situations:
// Example One
AContainer container1 = new AContainer();
SomeDisposableObject obj1 = container1.SomeObject;
container1.Dispose();
obj1.DoSomething(); // BAD because obj1 has been disposed by container1.
// Example Two
AContainer container2 = new AContainer();
SomeObject obj2 = new SomeObject();
container2.SomeObject = obj2; // BAD because the previous value of SomeObject not disposed.
container2.Dispose();
obj2.DoSomething(); // BAD because obj2 has been disposed by container2, which doesn't really "own" it anyway.
Does that help?

There is no single answer, it depends on your scenario, and the key point is ownership of the disposable resource represented by the property, as Jon Skeet points out.
It's sometimes helpful to look at examples from the .NET Framework. Here are three examples that behave differently:
Container always disposes. System.IO.StreamReader exposes a disposable property BaseStream. It is considered to own the underlying stream, and disposing the StreamReader always disposes the underlying stream.
Container never disposes. System.DirectoryServices.DirectoryEntry exposes a Parent property. It is not considered to own its parent, so disposing the DirectoryEntry never disposes its parent.
In this case a new DirectoryEntry instance is returned each time the Parent property is dereferenced, and the caller is presumably expected to dispose it. Arguably this breaks the guidelines for properties, and perhaps there should be a GetParent() method instead.
Container sometimes disposes. System.Data.SqlClient.SqlDataReader exposes a disposable Connection property, but the caller decides if the reader owns (and therefore disposes) the underlying connection using the CommandBehavior argument of SqlCommand.ExecuteReader.
Another interesting example is System.DirectoryServices.DirectorySearcher, which has a read/write disposable property SearchRoot. If this property is set from outside, then the underlying resource is assumed not to be owned, so isn't disposed by the container. If it's not set from outside, a reference is generated internally, and a flag is set to ensure it will be disposed. You can see this with Lutz Reflector.
You need to decide whether or not your container owns the resource, and make sure you document its behavior accurately.
If you do decide you own the resource, and the property is read/write, you need to make sure your setter disposes any reference it's replacing, e.g.:
public SomeDisposableObject SomeObject
{
get { return m_someObject; }
set
{
if ((m_someObject != null) &&
(!object.ReferenceEquals(m_someObject, value))
{
m_someObject.Dispose();
}
m_someObject = value;
}
}
private SomeDisposableObject m_someObject;
UPDATE: GrahamS rightly points out in comments that it's better to test for m_someObject != value in the setter before disposing: I've updated the above example to take account of this (using ReferenceEquals rather than != to be explicit). Although in many real-world scenarios the existence of a setter might imply that the object is not owned by the container, and therefore won't be disposed.

It really depends on who notionally "owns" the disposable object. In some cases, you may want to be able to pass in the object, for instance in the constructor, without your class taking responsibility for cleaning it up. Other times you may want to clean it up yourself. If you're creating the object (as in your sample code) then it should almost certainly be your responsibility to clean it up.
As for the property - I don't think having a property should really transfer ownership or anything like that. If your type is responsible for disposing of the object, it should keep that responsibility.

The real problem might be your object oriented design. If AContainer is Disposed, all its member objects should also be disposed. If not it sound like you can dispose a body but want to keep the leg instance living. Doesn't sound right.

If you have an disposable object on your class you implement IDisposable with a Dispose method that disposes wrapped disposables. Now the calling code has to ensure that using() is used or that an equivalent try / finally code that disposes the object.

I'll try to answer my own question:
Avoid It in the First Place
The easiest way out of this situation is to refactor the code to avoid the problem entirely.
There are two obvious ways to do this.
External instance creation
If AContainer does not create a SomeDisposableObject instance, but instead relies on external code to supply it, then AContainer will no longer "own" the instance and is not responsible for disposing of it.
The externally created instance could be supplied via the constuctor or by setting the property.
public class AContainerClass
{
SomeDisposableObject m_someObject; // No creation here.
public AContainerClass(SomeDisposableObject someObject)
{
m_someObject = someObject;
}
public SomeDisposableObject SomeObject
{
get { return m_someObject; }
set { m_someObject = value; }
}
}
Keep the instance private
The main issue with the posted code is that the ownership is confused. At Dispose time the AContainer class cannot tell who owns the instance. It could be the instance that it created or it could be some other instance that was created externally and set via the property.
Even if it tracks this and knows for certain that it is dealing with the instance that it created, then it still cannot safely dispose of it as other classes may now have a reference to it that they obtained from the public property.
If the code can be refactored to avoid making the instance public (i.e. by removing the property entirely) then the issue goes away.
And If It Can't Be Avoided...
If for some reason the code cannot be refactored in these ways (as I stipulated in the question) then in my opinion you are left with some fairly difficult design choices.
Always Dispose of the instance
If you choose this approach then you are effectively declaring that AContainer will take ownership of the SomeDisposableObject instance when the property is set.
This makes sense in some situations, particularly where SomeDisposableObject is clearly a transient or subservient object. However it should be documented carefully as it requires the calling code to be aware of this transfer of ownership.
(It may be more appropriate to use a method, rather than a property, as the method name can be used to give a further hint about ownership).
public class AContainerClass: IDisposable
{
SomeDisposableObject m_someObject = new SomeDisposableObject();
public SomeDisposableObject SomeObject
{
get { return m_someObject; }
set
{
if (m_someObject != null && m_someObject != value)
m_someObject.Dispose();
m_someObject = value;
}
}
public void Dispose()
{
if (m_someObject != null)
m_someObject.Dispose();
GC.SuppressFinalize(this);
}
}
Only Dispose if still the original instance
In this approach you would track whether the instance was changed from the one originally created by AContainer and only dispose of it when it was the original. Here the ownership model is mixed. AContainer remains the owner of its own SomeDisposableObject instance, but if an external instance is supplied then it remains the responsibility of the external code to dispose of it.
This approach best reflects the actual situation here, but it can be difficult to implement correctly. The client code can still cause issues by performing operations like this:
AContainerClass aContainer = new AContainerClass();
SomeDisposableObject originalInstance = aContainer.SomeObject;
aContainer.SomeObject = new SomeDisposableObject();
aContainer.DoSomething();
aContainer.SomeObject = originalInstance;
Here a new instance was swapped in, a method called, then the original instance was restored. Unfortunately the AContainer will have called Dispose() on the original instance when it was replaced, so it is now invalid.
Just give Up and let the GC handle it
This is obviously less than ideal. If the SomeDisposableObject class really does contain some scarce resource then not disposing of it promptly will definitely cause you issues.
However it may also represent the most robust approach in terms of how the client code interacts with AContainer as it requires no special knowledge of how AContainer treats the ownership of the SomeDisposableObject instance.
If you know that the disposable resource isn't actually scarce on your system then this may actually be the best approach.
Some commenters have suggested that it may be possible to use reference counting to track if any other classes still have a reference to the SomeDisposableObject instance. This would be very useful as it would allow us to dispose of it only when we know it is safe to do so and otherwise just let the GC handle it.
However I am not aware of any C#/.NET API for determining the reference count of an object. If there is one then please let me know.

The reason you cannot safely call Dispose() on AContainer's instance of SomeDisposableObject is due to lack of encapsulation. The public property provides unrestricted access to part of the internal state. As this part of the internal state must obey the rules of the IDisposable protocol, it is important to make sure that is well encapsulated.
The problem is similar to allowing access to an instance used for locking. If you do that, it becomes much harder to determine where locks are acquired.
If you can avoid exposing your disposable instance the problem of who will handle the call to Dispose() goes away as well.

An interesting thing that I've encountered is that SqlCommand owns an SqlConnection (both implement IDisposable) instance usually. However calling dispose on the SqlCommand will NOT dispose the connection too.
I've discovered this also with the help of Stackoverflow right here.
So in other words it matters if the "child" (nested?) instance can/will be reused later.

In general, I think whoever creates the object should be responsible for Disposal. In this case, AContainer creates SomeDisposableObject, so it should be Disposed when AContainer is.
If, for some reason, you think that SomeDisposableObject should live longer than AContainer - I can only think of the following methods:
leave SomeDisposableObject unDisposed, in which case the GC will take care of it for you
give SomeDisposableObject a reference to AContainer (see WinForms Controls and Parent properties). As long as SomeDisposableObject is reachable, so is AContainer. That'll prevent the GC from Disposing AContainer, but if someone calls Dispose manually - well, you'd Dispose SomeDisposableObject. I'd say that's expected.
Implement SomeDisposableObject as a method, say CreateSomeDisposableObject(). That makes it clear(er) that the client is responsible for Disposal.
All in all, though - I'm not really sure the design makes sense. After all, you seem to be expecting client code like:
SomeDisposableObject d;
using (var c = new AContainer()) {
d = c.SomeObject;
}
// do something with d
That seems like broken client code to me. It's violating Law of Demeter, and plain ol' common sense to me.

Design you have mentioned here is not something could handle this scenario. You said there is a container for that class then it should dispose it along with itself. If other objects may be using it then it is not the container and scope of you class widens and it need to dispose at boundary of that scope.

You could just flag the Disposal in Dispose(). After all Disposal isn't a destructor - the object still exists.
so:
class AContainer : IDisposable
{
bool _isDisposed=false;
public void Dispose()
{
if (!_isDisposed)
{
// dispose
}
_isDisposed=true;
}
}
add this to your other class, too.