We Keep Coding

C# BlockingCollection Dispose method

Documentation of BlockingCollection<T> class has the following note:
Always call Dispose before you release your last reference to the
BlockingCollection<T>. Otherwise, the resources it is using will not be freed
until the garbage collector calls the BlockingCollection<T> object's Finalize
method.
And internal implementation of BlockingCollection<T> in C# has the following method:
/// <summary>
/// Releases resources used by the <see cref="T:System.Collections.Concurrent.BlockingCollection{T}"/> instance.
/// </summary>
/// <param name="disposing">Whether being disposed explicitly (true) or due to a finalizer (false).</param>
protected virtual void Dispose(bool disposing)
There is only one call of this Dispose with argument disposing: true and finalization suppress after the call. But, surprisingly for me, there is no explicit finalizer in the class, and even no call of Dispose(false).
It looks like Dispose function is relatively simple and it just removes references to different objects for GC speed up. In this case, GC will do this work for us in the case when we forget to call Dispose() explicitly.
Can someone spot the light on the internals of this class? What is the purpose of a method Dispose(bool disposing)? Is it common practice to implement this method for .NET core libraries even in cases when it is not needed?

I think the MSDN documentation for how to properly implement the dispose pattern is worth a read. However, the answer to your question is that BlockingCollection is not sealed. This means that it can be derived. The reason for the void Dispose(bool disposing) is to allow derived classes to properly de-allocate the resources of the base class. So, for example, I could implement
class Foo : BlockingCollection<string>
{
private bool disposed = false;
~Foo()
{
Dispose(false);
}
protected override void Dispose(bool disposing)
{
if (disposed)
{
return;
}
if (disposing)
{
// free managed resources
}
// free unmanaged resources
disposed = true;
base.Dispose(disposing);
}
}
By doing this, when Dispose() is called, the BlockingCollection will call Dispose(true) on Foo, which will eventually call Dispose(true) on BlockingCollection, and you get the benefit that the ~Foo() finalizer is suppressed. If the Dispose() method is not called, the finalizer is not suppressed, and it is called, allowing Foo to still deallocate its unmanaged resources.

Is it really needed to implement dispose pattern for managed resources only

I've read carefully through this article and it seems to clearly state that the dispose pattern should be implemented in all cases of IDisposable implementation. I'm trying to understand why I need to implement the dispose pattern in cases when my class holds only managed resources (i.e. other IDisposable members or safe handles). Why cannot I just write
class Foo : IDisposable
{
IDisposable boo;
void Dispose()
{
boo?.Dispose();
}
}
If it's definitely known that there are no unmanaged resources and there is no point to call Dispose method from finalizer as managed resources aren't being freed from finalizer?
Update: In order to add some clarity. The discussion seems to come down to the question whether it's needed to implement the dispose pattern for every base public non-sealed class which implements IDisposable or not. I however cannot find potential problems with hierarchy when a base class without unmanaged resources doesn't use dispose pattern while child classes which have unmanaged resources do use this pattern:
class Foo : IDisposable
{
IDisposable boo;
public virtual void Dispose()
{
boo?.Dispose();
}
}
// child class which holds umanaged resources and implements dispose pattern
class Bar : Foo
{
bool disposed;
IntPtr unmanagedResource = IntPtr.Zero;
~Bar()
{
Dispose(false);
}
public override void Dispose()
{
base.Dispose();
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (disposed)
return;
if (disposing)
{
// Free any other managed objects here.
//
}
// close handle
disposed = true;
}
}
// another child class which doesn't hold unmanaged resources and merely uses Dispose
class Far : Foo
{
private IDisposable anotherDisposable;
public override void Dispose()
{
base.Dispose();
anotherDisposable?.Dispose();
}
}
Even more, for me it looks as better separation of concerns when implementations are responsible only for those things which they are aware of.

This
private class Foo : IDisposable
{
IDisposable boo;
public void Dispose()
{
boo?.Dispose();
}
}
Is perfectly fine. As is
public sealed class Foo : IDisposable
{
IDisposable boo;
public void Dispose()
{
boo?.Dispose();
}
}
What could go wrong if I have public not sealed base class implemented as above with virtual Dispose method ?
From the docs:
Because the order in which the garbage collector destroys managed
objects during finalization is not defined, calling this Dispose
overload with a value of false prevents the finalizer from trying to
release managed resources that may have already been reclaimed.
Accessing a managed object that has already been reclaimed, or accessing its properties after it's been Disposed (perhaps by another finalizer) will cause an Exception to be raised in the Finalizer, which is bad:
If Finalize or an override of Finalize throws an exception, and the
runtime is not hosted by an application that overrides the default
policy, the runtime terminates the process and no active try/finally
blocks or finalizers are executed. This behavior ensures process
integrity if the finalizer cannot free or destroy resources.
So if you had:
public class Foo : IDisposable
{
IDisposable boo;
public virtual void Dispose()
{
boo?.Dispose();
}
}
public class Bar : Foo
{
IntPtr unmanagedResource = IntPtr.Zero;
~Bar()
{
this.Dispose();
}
public override void Dispose()
{
CloseHandle(unmanagedResource);
base.Dispose();
}
void CloseHandle(IntPtr ptr)
{
//whatever
}
}
~Bar -> Bar.Dispose() -> base.Dispose() -> boo.Dispose() But boo may have been reclaimed by the GC.

I haven't seen this particular usage of Dispose mentioned yet, so I thought I'd point out a common source of memory leaks when not using the dispose pattern.
Visual Studio 2017 actually complains about this via static code analysis that I should "implement the dispose pattern". Do note I'm using SonarQube and SolarLint, and I don't believe Visual Studio will catch this alone. FxCop (another static code analysis tool) likely will, although I didn't test that.
I note the below code to showcase the dispose pattern is also there to protect against something like this, which has no unmanaged resources:
public class Foo : IDisposable
{
IDisposable boo;
public void Dispose()
{
boo?.Dispose();
}
}
public class Bar : Foo
{
//Memory leak possible here
public event EventHandler SomeEvent;
//Also bad code, but will compile
public void Dispose()
{
someEvent = null;
//Still bad code even with this line
base.Dispose();
}
}
The above illustrates very bad code. Don't do this. Why is this horrific code? That's because of this:
Foo foo = new Bar();
//Does NOT call Bar.Dispose()
foo.Dispose();
Let's assume this horrific code was exposed in our public API. Consider the above classes used by consumers of it:
public sealed class UsesFoo : IDisposable
{
public Foo MyFoo { get; }
public UsesFoo(Foo foo)
{
MyFoo = foo;
}
public void Dispose()
{
MyFoo?.Dispose();
}
}
public static class UsesFooFactory
{
public static UsesFoo Create()
{
var bar = new Bar();
bar.SomeEvent += Bar_SomeEvent;
return new UsesFoo(bar);
}
private static void Bar_SomeEvent(object sender, EventArgs e)
{
//Do stuff
}
}
Are the consumers perfect? No.... UsesFooFactory should probably also unsubscribe from the event. But it does highlight a common scenario where an event subscriber outlives the publisher.
I've seen events cause countless memory leaks. Especially in very large or extreme high performance codebases.
I can also hardly count how many times I've seen objects live long past their time of disposal. This is a very common way many profilers find memory leaks (disposed objects still held onto by a GC Root of some kind).
Again, overly simplified example and horrible code. But it's really never good practice to call Dispose on an object and not expect it to dispose the entire object, whether it has been derived from a million times or not.
Edit
Please note this answer is intentionally only addressing managed resources, showcasing that the dispose pattern is useful in this scenario as well. This purposefully does not address the use case for unmanaged resources as I felt there was a lack of focus on managed only uses. And there are many other good answers on here that talk about that.
I will, however, note a few quick things that are important when it comes to unmanaged resources. The above code might not address unmanaged resources, but I want to make clear it does not contradict how they should be handled.
It's extremely important to use finalizers when your class is responsible for unmanaged resources. Briefly, finalizers are automatically called by the Garbage Collector. So it gives you a reasonable guarantee that it always gets called at some point in time. It's not bulletproof, but a far cry from hoping user code calls Dispose.
This guarantee is not true of Dispose. An object can be reclaimed by the GC without Dispose ever being called. That's the key reason finalizers are used for unmanaged resources. The GC itself only handles managed resources.
But I will also note it's equally important finalizers should not be used to clean up managed resources. There are countless reasons why (it's the GC's job to do this after all) but one of the largest drawbacks to using finalizers is delaying garbage collection on an object.
The GC, seeing an object is free to reclaim but has a finalizer, will delay the collection by placing the object in the finalizer queue. This adds significant unnecessary lifetime to an object, plus more pressure on the GC.
Finally I'll note that finalizers are non-deterministic for this reason, despite having similar syntax to something like a destructor in C++. They are very different beasts. You should never rely upon a finalizer to clean up unmanaged resources at a specific point in time.

You probably got it wrong. You don't need to implement finilizer if you don't have unmanaged resources. You can check it by using automatic pattern implementation in Visual Studio (it will even generate the comments saying that you should uncomment the finalizer ONLY if you use unmanaged resources).
The dispose pattern is used only for objects that access unmanaged resources.
If you design a base class and some of the inheriting classes access unmanaged resources, the inheriting classes will deal with it themselves by overriding Dispose(bool) and defining the finalizer.
It's explained in this article, all finalizers will be called anyway if not suppressed. And if suppressed everything would have been released by the chain of Diapose(true) calls in the first place.

If Dispose() is implemented using a public virtual method, derived classes that expect to override that method can do so and all will be well. If, however, anything on the inheritance chain implements IDisposable.Dispose() via means other than overriding the public virtual Dispose() method, that can make it impossible for a sub-derived class to implement its own IDisposable.Dispose() while still being able to access the parent implementation.
The Dispose(bool) pattern can be used regardless of whether or not there is a public Dispose() method, and thus avoids the need to have separate patterns for the cases where a class does or does not expose a public Dispose() method. The GC.SuppressFinalize(this) could generally be replaced by a GC.KeepAlive(this), but for classes without finalizers the cost is about the same. In the absence of that call, the finalizers for any objects to which a class holds a reference could get triggered while the class' own Dispose method is running. Not a likely scenario, nor one that would usually cause problems even if it occurs, but passing this to GC.KeepAlive(Object) or GC.SuppressFinalize(Object) makes such quirky situations impossible.

Where should a C# COM server call dispose its resources?

I have a COM object implemented in C# (see below). It owns some IDisposable resource. Where should I dispose that resource?
Looks like finalizer is never called and I cannot overload IUnknown::Release method.
[ComVisible(true)]
[Guid("1992EC2F-087A-4264-B5B2-5E2E757F1A75")]
public class ComServer
{
IDisposable disposableResource; //where to dispose IDisposable resource?
public ComServer()
{
disposableResource = File.Open(#"c:\somefile.txt", FileMode.OpenOrCreate);
Console.WriteLine("ComServer.ComServer");
}
~ComServer() //finalizer is never called!
{
disposableResource.Dispose();
Console.WriteLine("ComServer.~ComServer");
}
}
Edited: the COM server is used in a native third party application, it's impossible to call Dispose on client side or make any changes there.

There is no guarantee when of if the finalize will be called. Your ComServer should implement the IDiposable interface itself and release it's disposable members within it.
From MSDN (if you override Object.Finalize)
If you are defining a base class that uses unmanaged resources and
that either has, or is likely to have, subclasses that should be
disposed, you should implement the IDisposable.Dispose method and
provide a second overload of Dispose, as discussed in the next
section.
class BaseClass : IDisposable
{
// Flag: Has Dispose already been called?
bool disposed = false;
// Public implementation of Dispose pattern callable by consumers.
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
// Protected implementation of Dispose pattern.
protected virtual void Dispose(bool disposing)
{
if (disposed)
return;
if (disposing) {
// Free any other managed objects here.
//
}
// Free any unmanaged objects here.
//
disposed = true;
}
~BaseClass()
{
Dispose(false);
}
}
Then call Dispose explicitly if you need it disposed or use using where ever possible.
using(ComServer com = new ComServer()) {
// operate on the ComServer
} // Dispose will be called automatically when the leaving the using block

Finalizer will never be called if your object is not marked for garbage collection. Go and look for the reason.
As to Dispose, only you can decide when to dispose your objects. It depends on the architecture, lifecycle of your objects. Generally speaking, you should call Dispose() when the object is no longer needed.
The best thing you can do is to implement IDisposable on your ComServer and invoke Dispose where your objects are no longer needed, or you can just wrap them in using constructions.
Tseng provided an example of standard implementation of IDisposable pattern, though consider that a good program does not need finalizers. Generally, it's a bad practice to leave your objects with intention to rely upon the mechanism of finalizing.
If you want to test your finalizer, than you can create your object, do not dispose it, call GC.Collect(). This call will force the garbage collection and if your object is eligible for garbage collection your finalizer will be invoked. But just remember never to use GC.Collect() as part of your production code.

dispose vs finalize how the object free the memory?

I want to know should we use dispose and finalize if we are to deal with an object that is holding an unmanaged resource.
second thing if we dispose an object does that object release memory along with the unmanaged resource on that moment only or that object's memory will be released by garbage collector later. same thing i want to know in fianilize context, once we finalize an object does that release memory for that object on the definite time or we have wait until garbage collector frees it's memory.

You should prevent users of your application from calling an object's Finalize method directly by limiting its scope to protected. In addition, you are strongly discouraged from calling a Finalize method for a class other than your base class directly from your application's code. To properly dispose of unmanaged resources, it is recommended that you implement a public Dispose or Close method that executes the necessary cleanup code for the object. The IDisposable interface provides the Dispose method for resource classes that implement the interface. Because it is public, users of your application can call the Dispose method directly to free memory used by unmanaged resources. When you properly implement a Dispose method, the Finalize method becomes a safeguard to clean up resources in the event that the Dispose method is not called.
// Design pattern for a base class.
public class Base: IDisposable
{
private bool disposed = false;
//Implement IDisposable.
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
// Free other state (managed objects).
}
// Free your own state (unmanaged objects).
// Set large fields to null.
disposed = true;
}
}
// Use C# destructor syntax for finalization code.
~Base()
{
// Simply call Dispose(false).
Dispose (false);
}
}
// Design pattern for a derived class.
public class Derived: Base
{
private bool disposed = false;
protected override void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
// Release managed resources.
}
// Release unmanaged resources.
// Set large fields to null.
// Call Dispose on your base class.
disposed = true;
}
base.Dispose(disposing);
}
// The derived class does not have a Finalize method
// or a Dispose method without parameters because it inherits
// them from the base class.
}
Source: MSND

As the implementer of a class, if you hold managed resources that ought to be disposed, you implement Dispose. If you hold native resources, you implement both Dispose and Finalize, and both call a common method that releases the native resources.
This is very well described in msdn Implementing Finalize and Dispose to Clean Up Unmanaged Resources

Both. The Dispose method is where resources are released and it's Dispose that you call explicitly in code when you're done with an object. Finalize doesn't do any work itself but rather just calls Dispose. If you don;t call Dispose yourself in your code then the garbage collector will call Finalize at some point in order to release the resources held by the object.
Memory is not considered to be a resource for the purposes of disposal. Once an object has been disposed and there are no more references to it, then the garbage collector can free the memory it occupies. Think about it. Calling Close on a form disposes it but the form still exists, so obviously the memory it occupies has not been released. Only the window handle is released.

I want to know should we use dispose and finalize if we are to deal with an object that is holding an unmanaged resource
Not necessarily, Dispose itself enough if you will make sure you call Dispose for sure. If not it is recommended to implement finalizer which is called by GC at the time of reclaiming memory.(Note: It is not reliable, meaning it may not be called also!).
second thing if we dispose an object does that object release memory
along with the unmanaged resource on that moment only or that object's
memory will be released by garbage collector later
No, disposing won't release memory. GC will do that once it sees it is time to reclaim. It is in-deterministic. Keep in mind Disposing means just calling some method named Dispose that's it, nothing else.
once we finalize an object does that release memory for that object on
the definite time or we have wait until garbage collector frees it's
memory.
Hypothetical question, It is expected that immediately after Finalizer called object will be released from memory, but Eric says A destructor can "resurrect" an object, making a dead object alive again. That's really weird. Don't do it. So I think hard to answer this question.
Hope this helps.

We should use Dispose whenever we operate with unmanaged resources, the typical scheme is
public class Wrapper: IDisposable {
...
// Let's acquire resource in constructor
public Wrapper(...) {
...
AcquireResource();
...
}
public Boolean IsDisposed {
get;
protected set; // <- Or even "private set"
}
protected virtual Dispose(Boolean disposing) {
if (IsDisposed)
return;
if (disposing) {
ReleaseResource();
}
IsDisposed = true;
}
public Dispose() {
Dispose(true);
GC.SuppressFinalize(this);
}
}
Do not use finalize: since finalization is called by GC and that's why
in unpredictable moments of time each error/leak in Dispose will be
floating error (and harder to detect) if you call Dispose(false) from ~Wrapper. The only, IMHO, case when you may want to implement finalization is when you acquire
unmanaged memory chunk:
public class MemoryWrapper: IDisposable {
private IntPtr m_Handle;
private int m_Size;
public void AcquireMemory(int size) {
...
m_Size = size;
m_Handle = UnmanagedAcquireMemory(size);
// Let GC know that we acquire memory in some weird way
GC.AddMemoryPressure(size);
}
private void ReleaseMemory() {
...
UnmanagedReleaseMemory(m_Handle, m_Size);
// Let GC know that we release memory in some weird way
GC.RemoveMemoryPressure(m_Size);
}
private MemoryWrapper(int size) {
AcquireMemory(size);
}
public Boolean IsDisposed {
get;
protected set; // <- Or even "private set"
}
protected virtual Dispose(Boolean disposing) {
if (IsDisposed)
return;
ReleaseMemory();
IsDisposed = true;
}
public Dispose() {
Dispose(true);
GC.SuppressFinalize(this);
}
// Possible finalizer
~MemoryWrapper() {
Dispose(false);
}
}
For typical resources wrappers the best way is to use special classes like
SafeHandle
SafeHandleZeroOrMinusOneIsInvalid
http://msdn.microsoft.com/query/dev11.query?appId=Dev11IDEF1&l=EN-US&k=k(System.Runtime.InteropServices.SafeHandle);k(TargetFrameworkMoniker-.NETFramework,Version%3Dv4.5);k(DevLang-csharp)&rd=true

Is this IDisposable implementation correct?

I can never remember all the rules for implementing the IDisposable interface, so I tried to come up with a base class that takes care of all of this and makes IDisposable easy to implement. I just wanted to hear your opinion if this implementation is ok as it is or whether you see something I could improve. The user of this base class is supposed to derive from it and then implement the two abstract methods ReleaseManagedResources() and ReleaseUnmanagedResources(). So here is the code:
public abstract class Disposable : IDisposable
{
private bool _isDisposed;
private readonly object _disposeLock = new object();
/// <summary>
/// called by users of this class to free managed and unmanaged resources
/// </summary>
public void Dispose() {
DisposeManagedAndUnmanagedResources();
}
/// <summary>
/// finalizer is called by garbage collector to free unmanaged resources
/// </summary>
~Disposable() { //finalizer of derived class will automatically call it's base finalizer
DisposeUnmanagedResources();
}
private void DisposeManagedAndUnmanagedResources() {
lock (_disposeLock) //make thread-safe
if (!_isDisposed) { //make sure only called once
try { //suppress exceptions
ReleaseManagedResources();
ReleaseUnmanagedResources();
}
finally {
GC.SuppressFinalize(this); //remove from finalization queue since cleaup already done, so it's not necessary the garbage collector to call Finalize() anymore
_isDisposed = true;
}
}
}
private void DisposeUnmanagedResources() {
lock (_disposeLock) //make thread-safe since at least the finalizer runs in a different thread
if (!_isDisposed) { //make sure only called once
try { //suppress exceptions
ReleaseUnmanagedResources();
}
finally {
_isDisposed = true;
}
}
}
protected abstract void ReleaseManagedResources();
protected abstract void ReleaseUnmanagedResources();
}

I can't really comment on the correctness of your code, but I question whether you'll find having the Disposable class at the base of your inheritance tree as flexible as it needs to be. It's won't be much use when you want to inherit from something you don't own. I think that IDispoasble is left as an interface because of the many different domains across which it might be used. Providing a concrete implementation at the foot of the inheritance hierarchy would be... limiting.

You are accessing the managed object _disposeLock in the finalizer. It may have already been garbage-collected by then. Not sure what the implications of this would be as you are only using it to lock.
Thread-safety seems like overkill. I don't think you need to worry about contention between the GC thread and your application thread.
Otherwise it looks correct.

EDIT Yes, I misread the portion about separating disposing managed and unmanaged resources (still on first cup of coffee).
However the lock is still almost certainly not necessary. Yes, during a passive dispose the code will be running on the finalizer thread which is different than the thread it originally ran on. However if the object is being finalized in this fashion the CLR has already determined there are no existing references to this object and hence collected it. So there is no other place which can be calling your dispose at that time and hence there is no reason for a lock.
A couple of other style comments.
Why make the methods abstract? By doing so you are forcing derived classes to implement methods to dispose of managed and unmanaged resources even if they don't have any to dispose. True there is no point in deriving from this class if you don't have anything to dispose. But I think it's fairly common to only have one or the other but not both. I would make them virtual vs. abstract.
Also you prevent double dispose but you do nothing to warning the developer that they are double disposing an object. I realize the MSDN documentation says that double dispose should be essentially a no-op but at the same time under what circumstances should this be legal? In general it's a bad idea to access an object after it's been disposed. A double dispose necessitates a disposed object being reused and is likely a bug (this can happen if finalization is not suppressed in an active dispose but that's also a bad idea). If I were implementing this I would throw on double dispose to warn the developer they were using an object incorrectly (that is using it after it was already disposed).

If you are concerned about the thread safety then I'd use the lightweight interlocked operations rather than a heavyweight lock:
class MyClass: IDispose {
int disposed = 0;
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
public virtual void Dispose(bool disposing)
{
if (0 == Thread.InterlockedCompareExchange(ref disposed, 1, 0))
{
if (disposing)
{
// release managed resources here
}
// release unmanaged resources here
}
}
~MyClass()
{
Dispose(false);
}
}