We Keep Coding

using (IDisposable) vs. class field - correct usage of ReaderWriterLockSlim

In a FileWriter class that will be used by different threads, I currently use a ReaderWriterLockSlim to prevent errors occurring when two threads try to write to the file at the same time like this:
(1)
public class FileWriter
{
private ReaderWriterLockSlim readerWriterLock = new ReaderWriterLockSlim();
public void WriteToFile(string message)
{
try
{
this.readerWriterLock.EnterWriteLock();
// the writing happens here
}
finally
{
this.readerWriterLockSlim.ExitWriteLock();
}
}
}
which does work. But after that, I read that ReaderWriterLockSlim implements IDisposable, and so I wondered whether
(2)
public class FileWriter
{
public void WriteToFile(string message)
{
using (ReaderWriterLockSlim readerWriterLockSlim = new ReaderWriterLockSlim())
{
readerWriterLockSlim.EnterWriteLock();
// the writing happens here
readerWriterLockSlim.ExitWriteLock();
}
}
}
would be the "better" approach and whether it might introduce some new drawbacks. My gut feeling tells me that I probably shouldn't create a new ReaderWriterLockSlim every time the method is called but rather only once as in (2).
Sadly though, it does not work (it's as if I hadn't even used a lock) and so I figured that (2) can't be correct.
But then again, why would ReaderWriterLockSlim implement IDisposable if it wasn't planned to be used as in (2)?
What is the correct usage of ReaderWriterLockSlim?

Not every IDisposable is directly used in a using statement. The other pattern is if you have an IDisposable in one of your classes fields (and your class "owns" that object1), then your class should also implement IDisposable and clean up its disposables during Dispose.
You're correct that your re-write is wrong, since every caller is using a different lock object and so no exclusion is happening.
See Dispose Pattern:
DO implement the Basic Dispose Pattern on types containing instances of disposable types. See the Basic Dispose Pattern section for details on the basic pattern.
1Thanks to Dirk's comment for the important caveat. If you're in a situation where you're not trying to control an object's lifetime, it's not appropriate to Dispose of such objects

Does C# automatically "dispose" IDisposable objects when they fall out of scope?

I am writing an ASP.NET Web API. As part of this, I have a class that I found out, during testing, needs to implement IDisposable to ensure managed resources are freed.
So, I implemented IDisposable in my class, and put the code necessary to free the resources in the Dispose() method.
There are many places in my code (hundreds) where I instantiate this object, and in the same line call a method on the new instance. I only need the instance to call the single method.
Here's an example:
// MyObject, a class that needs to be disposed of.
public class MyObject : IDisposable
{
private AnObjectThatMustBeDisposed localObject;
public MyObject()
{
localObject = SomeLibrary.SomeProject.AnObjectThatMustBeDisposed.Create();
}
public void doOperationOne()
{
localObject.DoSomething(1);
}
public string getOperationTwo()
{
return localObject.DoSomething(2);
}
public string getOperationThree()
{
return localObject.DoSomething(3);
}
public bool getOperationFour(string input)
{
return localObject.DoSomethingSpecial(4,input.ToLower());
}
...
public void getOperationOneHundred(DateTime input)
{
localObject.DoSomethingElse(100,input);
}
public void Dispose()
{
localObject.CloseResources();
localObject.FreeUpMemory();
localObject.Close();
localObject.Dispose();
}
}
// A class that makes use of MyObject
public class MyLibraryThatUsesMyObject
{
public void Method1()
{
new MyObject().doOperationOne();
}
public string Method2()
{
return new MyObject().getOperationTwo();
}
public int Method3()
{
return new MyObject().getOperationThree();
}
public bool Method4(string testString)
{
if (testString.Length > 6)
{
if (new MyObject().getOperationFour(testString)) return true;
else return false;
}
else return false;
}
...
public void Method100()
{
new MyObject().doOperationOneHundred(DateTime.Now);
}
}
My question is: Does .NET automatically Dispose() objects when they fall out of scope? Or, do I actually have to do this...
public void Method1()
{
using (MyObject o = new MyObject())
{
o.DoOperationOne();
}
}
...to each method? It wouldn't be hard if I had two or three methods, but if I have tons of methods, this refactoring could take quite a while.
I am not sure how ASP.NET handles requests as they complete - i.e. does the framework give code time to Dispose() things, or does it "cut off" execution as soon as the return is called, not letting things dispose?
The fact that, without implementing IDisposable myself, things inside the MyObject class are failing due to unreleased resources causing leaks, it feels like .NET does not automatically Dispose things. So, if that's the case, can I do something so I don't have to refactor hundreds of methods?
EDIT: I tried simply implementing IDisposable, but my unit test was still able to produce a resource leak. So it would appear that my suspicion that .NET is not automatically disposing is correct. So now my question becomes - how can I force disposing without having to refactor hundreds of methods?

Dispose is not automatically called. If you don't call .Dispose() (either explicitly or via a using statement) the method will never be called.
The only caveat is methods that are implemented with the pattern
public void Dispose()
{
GC.SuppressFinalize(this);
Dispose(true);
}
~MyClass()
{
Dispose(false);
}
bool _isDisposed = false;
protected virtual void Dispose(bool disposeing)
{
if(_isDisposed)
return;
_isDisposed = true;
if(disposing)
{
//Disposed managed code here
}
//Dispose unmanaged code only here.
}
Will have Dispose(false) called on it when the object is finalized, but you are not allowed to dispose (or even access) managed objects (i.e: other stuff that implements .Dispose()) when disposing is false.
You will need to refactor your code if you want your resources disposed correctly.
There is a really, really, good article written by Stephen Cleary "IDisposable: What Your Mother Never Told You About Resource Deallocation" that does a very good job explaining how Dispose works and how to correctly write your own disposeable objects (for example, that caveat pattern I mentioned above is recommended by Microsoft but is actually a very bad pattern to do. Classes should only either hold only managed resources or derive from SafeHandle and only hold a unmanaged resource and possibly other SafeHandles. You should never have a class that holds both managed and unmanaged resources nor a single class that holds multiple unmanaged resources)

I am not sure how ASP.NET handles requests as they complete - i.e. does the framework give code time to Dispose() things, or does it "cut off" execution as soon as the return is called, not letting things dispose?
My answer will try to answer the specific question above since you have gotten answers to your other question.
In the MVC framework there is a class that creates controllers. It is named DefaultControllerFactory and it has this method:
public virtual void ReleaseController(IController controller)
{
IDisposable disposable = controller as IDisposable;
if (disposable != null)
{
disposable.Dispose();
}
}
Please note the parameter the above method takes: IController. So it passes your controller class (since all controllers implement that interface by deriving the BaseController) and if your controller implements IDisposable, it will cast it and then call Dispose() on it. So it gives you a chance to do whatever cleanup you need to do.
If you have rolled your own factory and you are not using the DefaultControllerFactory then make sure you are doing the same thing and calling the Dispose on the controllers.
I got the above source code from MVC's Source Code.

No, the CLR will never call Dispose on your object when it goes out of scope. It will, however, call the class destructor (which must be explicitly overridden).
Note: The example that follows is not intended to demonstrate what should be done in production code. The practice recommended by Microsoft can be found here.
Consider the following class:
public class MyDisposable : IDisposable
{
public void Dispose()
{
Console.WriteLine("Disposing this disposable instance.");
}
// Note: This is not the right way to implement the dispose pattern. See
// the MSDN docs on the recommended pattern.
~MyDisposable()
{
Dispose();
}
}
Now, write this method that uses it, and set a break point on the MyDispoable.Dispose method.
private static void UseDisposable()
{
Console.WriteLine("Enter");
var disposable = new MyDisposable();
Console.WriteLine("Exit");
}
What you will see is that, when leaving this scope, not only is the Dispose on MyDisposable not called, but neither is the finalizer. This means that the locals you created in your method are not cleaned up at the end of the method, even though they are local to the method (not returned to the caller, or assigned to any other object).
The way that I try to manage disposable resources in my own code is by not using them as class members, and put all of them inside of using blocks. Keep in mind that a using is only syntax sugar for try {...} finally {...}, though.
Now, I think your question is more about ASP.NET than the CLR. I am not sure of what ASP.NET does to handle disposable resources. If you are using the resource inside of a Controller, then have a go at implementing IDisposable, and using a break point to see if it gets called after your method completes. That's a scenario that I'm not as sure about, but it seems reasonable that it may work that way.
Edit: See the answer from #CodingYoshi regarding ASP.NET controller disposal. It turns out that MVC will deterministically call dispose, so some of your refactoring may be slightly more simple.

What is lazy instantiation

Is lazy instantiation about using less code but getting the same result? Surely this is generally a good thing to do (providing making the code to short / efficient doesn't damage readability/maintainability).
Please refer to this lazy instantiation:
public sealed class Singleton
{
private Singleton()
{
}
public static Singleton Instance { get { return Nested.instance; } }
private class Nested
{
// Explicit static constructor to tell C# compiler
// not to mark type as beforefieldinit
static Nested()
{
}
internal static readonly Singleton instance = new Singleton();
}
}
There is no private property of Instance (I know it's implicit) - is it that which makes it lazy - the fact we don't have a setter within the public static Singleton Instance property?

Lets say we have a field of a type that is expensive to construct
class Foo
{
public readonly Expensive expensive = new Expensive();
...
}
The problem with this code is that instansiating Foo incurs the performance cost of instansiating Expensive - whether-or-not the Expensive field is ever accessed. The obvious answer is to construct the instance on demand or lazily instansiate the field:
class Foo
{
Expensive _expensive;
public Expensive
{
get
{
if (_expensive == null) _expensive = new Expensive();
return _expensive;
}
}
...
}
This is lazy instansiation.

Lazy initialization is a practice whereby you only load or initialize an object when you first need it.
Potentially, this can give you a big performance boost, especially if you have a vast amount of components in your application.
Look at the Wikipedia page for a greater insight (it features coded examples).

No, lazy instantiation means not spending any time and resources creating something until you actually need it.
In your singleton example, the instance is just an empty reference, until it's actually used. When it's used, then you spend the resources to instantiate the object with a new.

Lazy initialization of an object means that its creation is deferred until it is first used.
For complete reference see msdn post Lazy Initialization
In your above code, the instance of the singleton class is not created until you call it.
So, your program will not use resources until your code gets called.

It's lazy because the instance of the class Singleton isn't created until the first time you ask for it.

Is there any benefit to implementing IDisposable on classes which do not have resources?

In C#, if a class, such as a manager class, does not have resources, is there any benefit to having it : IDisposable?
Simple example:
public interface IBoxManager
{
int addBox(Box b);
}
public class BoxManager : IBoxManager
{
public int addBox(Box b)
{
using(dataContext db = new dataContext()){
db.Boxes.add(b);
db.SaveChanges();
}
return b.id;
}
}
Will there be any benefit in memory use when using BoxManager if it also implements IDisposable? public class BoxManager : IBoxManager , IDisposable
For example:
BoxManager bm = new BoxManager();
bm.add(myBox);
bm.dispose();//is there benefit to doing this?

There are only 2 reasons for implementing IDisposable on a type
The type contains native resources which must be freed when the type is no longer used
The type contains fields of type IDisposable
If neither of these are true then don't implement IDisposable
EDIT
Several people have mentioned that IDisposable is a nice way to implement begin / end or bookended operations. While that's not the original intent of IDisposable it does provide for a very nice pattern.
class Operation {
class Helper : IDisposable {
internal Operation Operation;
public void Dispose() {
Operation.EndOperation();
}
}
public IDisposable BeginOperation() {
...
return new Helper() { Operation = this };
}
private void EndOperation() {
...
}
}
Note: Another interesting way to implement this pattern is with lambdas. Instead of giving an IDisposable back to the user and hoping they don't forget to call Dispose have them give you a lambda in which they can execute the operation and you close out the operation
public void BeginOperation(Action action) {
BeginOperationCore();
try {
action();
} finally {
EndOperation();
}
}

There won't be a scrap of difference between the disposable and non-disposable version if you don't explicitly make use of the Dispose() method.

While your code wouldn't benefit from implementing IDisposable, I can't agree with other opinions here that state that IDisposable is only meant to (directly or indirectly) free native resources. IDisposable can be used whenever the object needs to perform clean up task at the end of it's lifetime span. It's extremely useful together with using.
A very popular example: in ASP.NET MVC Html.BeginForm returns an IDisposable. On creation, the object opens the tag, when Dispose is called it closes it. No native resources involved, yet still a good use of IDisposable.

No, there will be no benefit if you don't do something useful like releasing unmanaged resources that your class might hold in the Dispose method.

One major point of confusion, which may not be applicable in your case but arises often, is what exactly constitutes a "resource". From the perspective of an object, an unmanaged resource is something which an outside entity () is "doing"(*) on its behalf, which that outside entity will keep doing--to the detriment of other entitites--until told to stop. For example, if an object opens a file, the machine which hosts the file may grant that object exclusive access, denying everyone else in the universe a chance to use it unless or until it gets notified that the exclusive access isn't needed anymore.
(*) which could be anything, anywhere; possibly not even on the same computer.
(**) or some way in which the the behavior or state of an outside entity is altered
If an outside entity is doing something on behalf of an object which is abandoned and disappears without first letting the entity know its services are no longer required, the outside entity will have no way of knowing that it should stop acting on behalf of the object which no longer exists. IDisposable provides one way of avoiding this problem by providing a standard means of notifying objects when their services are not required. An object whose services are no longer required will generally not need to ask any further favors from any other entities, and will thus be able to request that any entities that had been acting on its behalf should stop doing so.
To allow for the case where an object gets abandoned without IDisposable.Dispose() having been called first, the system allows objects to register a "failsafe" cleanup method called Finalize(). Because for whatever reason, the creators of C# don't like the term Finalize(), the language requires the use of a construct called a "destructor" which does much the same thing. Note that in general, Finalize() will mask rather than solve problems, and can create problems of its own, so it should be used with extreme caution if at all.
A "managed resource" is typically a name given to an object which implements IDisposable and usually, though not always, implements a finalizer.

No, if there are no (managed or unmanaged) resources there is no need for IDisposable either.
Small caveat: some people use IDisposable to clean up eventhandlers or large memory buffers but
you don't seem to use those
it's a questionable pattern anyway.

From my personal experience (confirmed with discussion and other posts here) I would say, that there could be a situations where your object use massive amount of events, or not massive amount but frequent subscriptions and unsubscription from the event which sometimes leads to that the object is not garbage collected. In this case I in Dispose unsubscribe from all events my object subscribed before.
Hope this helps.

IDisposable is also great if you want to benefit the using () {} syntax.
In a WPF project with ViewModels, I wanted to be able to temporarily disable NotifyPropertyChange events from raising. To be sure other developers will re-enable notifications, I wrote a bit of code to be able to write something like:
using (this.PreventNotifyPropertyChanges()) {
// in this block NotifyPropertyChanged won't be called when changing a property value
}
The syntax looks okay and is easily readable. For it to work, there's a bit of code to write. You will need a simple Disposable object and counter.
public class MyViewModel {
private volatile int notifyPropertylocks = 0; // number of locks
protected void NotifyPropertyChanged(string propertyName) {
if (this.notifyPropertylocks == 0) { // check the counter
this.NotifyPropertyChanged(...);
}
}
protected IDisposable PreventNotifyPropertyChanges() {
return new PropertyChangeLock(this);
}
public class PropertyChangeLock : IDisposable {
MyViewModel vm;
// creating this object will increment the lock counter
public PropertyChangeLock(MyViewModel vm) {
this.vm = vm;
this.vm.notifyPropertylocks += 1;
}
// disposing this object will decrement the lock counter
public void Dispose() {
if (this.vm != null) {
this.vm.notifyPropertylocks -= 1;
this.vm = null;
}
}
}
}
There are no resources to dispose here. I wanted a clean code with a kind of try/finally syntax. The using keyword looks better.

is there any benefit to having it : IDisposable?
It doesn't look so in your specific example, however: there is one good reason to implement IDisposable even if you don’t have any IDisposable fields: your descendants might.
This is one of the big architectural problems of IDisposable highlighted in IDisposable: What your mother never told you about resource deallocation. Basically, unless your class is sealed you need to decide whether your descendants are likely to have IDisposable members. And this isn't something you can realistically predict.
So, if your descendants are likely to have IDisposable members, that might be a good reason to implement IDisposable in the base class.

Short answer would be no. However, you can smartly use the nature of the Dispose() executement at the end of the object lifecycle. One have already gave a nice MVC example (Html.BeginForm)
I would like to point out one important aspect of IDisposable and using() {} statement. At the end of the Using statement Dispose() method is automatically called on the using context object (it must have implemented IDisposable interface, of course).

There one more reason that no one mentioned (though it's debateful if it really worth it):
The convension says that if someone uses a class that implement IDisposable, it must call its Dispose method (either explicitly or via the 'using' statement).
But what happens if V1 of a class (in your public API) didn't need IDisposable, but V2 does? Technically it doesn't break backward compatibility to add an interface to a class, but because of that convension, it is! Because old clients of your code won't call its Dispose method and may cause resources to not get freed.
The (almost) only way to avoid it is to implement IDisposable in any case you suspect that you'll need it in the future, to make sure that your clients always call your Dispose method, that some day may be really needed.
The other (and probably better) way is to implemet the lambda pattern mentioned by JaredPar above in the V2 of the API.

Have I been doing locks wrong this whole time?

I was reading this article about thread safety in Singletons, and it got me thinking that I don't understand the lock method.
In the second version, the author has this:
public sealed class Singleton
{
private static Singleton instance = null;
private static readonly object padlock = new object();
Singleton()
{
}
public static Singleton Instance
{
get
{
lock (padlock)
{
if (instance == null)
{
instance = new Singleton();
}
return instance;
}
}
}
}
Whereas I would've done something more like this:
public sealed class Singleton
{
private static Singleton instance = null;
Singleton()
{
}
public static Singleton Instance
{
get
{
lock (instance)
{
if (instance == null)
{
instance = new Singleton();
}
return instance;
}
}
}
}
Why would you use a padlock object, rather than locking the actual object you want to lock?

What would you expect to happen the first time you accessed the Instance property, before you've got an object to lock on?
(Hint: lock(null) goes bang...)
As a separate measure, I almost always avoid locking on "the actual object" - because typically there may well be other code which that reference is exposed to, and I don't necessarily know what that's going to lock on. Even if your version did work, what would happen if some external code wrote:
// Make sure only one thread is ever in this code...
lock (Singleton.Instance)
{
// Do stuff
}
Now no-one else can even get the instance while that code is executing, because they'll end up blocked in the getter. The lock in the getter isn't meant to be guarding against that - it's only meant to be guarding against multiple access within the getter.
The more tightly you can keep control of your locks, the easier it is to reason about them and to avoid deadlocks.
I very occasionally take a lock on a "normal" object if:
I'm not exposing that reference outside that class
I have confidence that the type itself (which will always have a reference to this, of course) won't lock on itself.
(All of this is a reason to avoid locking on this, too, of course...)
Fundamentally, I believe the idea of allowing you to lock on any object was a bad idea in Java, and it was a bad move to copy it in .NET :(

Locking on this or any other non-private object is dangerous because it can lead to deadlocks if someone else also tries to use that object for synchronization.
It's not terribly likely, which is why people can be in the habit of doing it for years without ever getting bitten. But it is still possible, and the cost of a private instance of object probably isn't great enough to justify running the risk.

For locking you can use any kind of object, the type really doesn't matter, it just used as a flag and only one thread can hold it in a time.
It is of course possible to have this as locking param. But I guess the main reason why it's not recommended is that other class somewhere can also use instance of your class as locking object and that can cause strage problems