We Keep Coding

Shared ownership of IDisposable objects in C#

Is there any classes in C# which provide shared ownership of IDisposable objects? Something like shared_ptr in c++? And if not, what are best practices here?
UPDATE
I'm writing a c++/cli wrapper over native lib. And I need release native resources (MAPI COM interfaces for example, so I need determenistic resource releasing).
Native part:
//Message.h
class Message
{ ... };
//MessageSet.h
class MessageSet
{
...
class iterator : public std::iterator<std::forward_iterator_tag, Message*>
{
...
public:
Message* operator*();
bool operator!=(const iterator& that);
iterator& operator++();
};
iterator begin();
iterator end();
};
Managed part (c++/cli):
public ref class Message
{
native::Message* inst;
public:
Message(native::Message* inst);
~Message();
!Message();
};
public ref class MessageSet : public IEnumerable<Message^>
{
native::MessageSet* inst;
public:
MessageSet(native::Message* inst);
~MessageSet();
!MessageSet();
virtual IEnumerator<Message^>^ GetEnumerator();
virtual System::Collections::IEnumerator^ EnumerableGetEnumerator() = System::Collections::IEnumerable::GetEnumerator;
};
When I use Message objects in TPL Dataflow (BroadcastBlock block i.e. there are many concurrent consumers) in C# I don't know when I should call Dispose() for these messages.

I think the best you could do is something like this:
public sealed class SharedDisposable<T> where T : IDisposable
{
public sealed class Reference : IDisposable
{
public Reference( SharedDisposable<T> owner )
{
mOwner = owner;
}
public void Dispose()
{
if( mIsDisposed ) return;
mIsDisposed = true;
mOwner.Release();
}
public T Value => mOwner.mValue;
private readonly SharedDisposable<T> mOwner;
private bool mIsDisposed;
}
public SharedDisposable( T value )
{
mValue = value;
}
public Reference Acquire()
{
lock( mLock )
{
if( mRefCount < 0 ) throw new ObjectDisposedException( typeof( T ).FullName );
mRefCount++;
return new Reference( this );
}
}
private void Release()
{
lock( mLock )
{
mRefCount--;
if( mRefCount <= 0 )
{
mValue.Dispose();
mRefCount = -1;
}
}
}
private readonly T mValue;
private readonly object mLock = new object();
private int mRefCount;
}
Basically this allows you to have one object (SharedDisposable<T>) manage the lifetime of the underlying disposable while providing a mechanism to distribute "shared" references to it.
One shortcoming here is that technically anyone could dispose the underlying value by accessing it through the shared reference Value property. You could address this by creating some sort of facade object that wraps the underlying disposable type but hides its Dispose method.

That would a NO.
Best way I found so far is quite clunky, using Dictionaries and WeakReferences. The Dictionary maps the object to it's refcount. WeakReference is used so you don't increase the ref count artificially.

You do not own IDisposable, you implement it, so .NET Garbage Collector will call overridden method in your class, notifying about a fact happened.
It's a different concept from shared_ptr, where destructor is guaranteed to be called once last ownership of a pointer is gone.
In general, in .NET, unless you are not using unsafe programming techniques, you do not own anything, .NET Garbage Collector owns it.
Even when you explicitly destroy an object, the memory allocated for it may not, and often will not, be reclaimed immediately, like once would expect from C++.
EDIT
If you have native resources and want release them in precise moment, you can achieve that by :
1) Implementing IDisposable with your .NET wrapper object
2) Inside Dispose() method of that wrapper write the code that releases native resources
3) In the code that consumes wrapper object, in the moment you would like to release native resources allocated by wrapper object, call explicitly Dispose() on it.
In this case Dispose() method is called, your code executes and releases native resources immediately.
EDIT (2)
After that is more clear what's the question about:
If you can not determine when Dispose() has to be called, I would stay with #Hans's comment: just relay on eventual (soon or later) GC call and avoid your own reference counter implementation (especially in multi threaded environment).
Do not invent the wheel, if that is a feasible in your situation.

Is there any issue with creating singleton following way in .Net ? [duplicate]

Isn't this a simpler as well as safe (and hence better) way to implement a singleton instead of doing double-checked locking mambo-jambo? Any drawbacks of this approach?
public class Singleton
{
private static Singleton _instance;
private Singleton() { Console.WriteLine("Instance created"); }
public static Singleton Instance
{
get
{
if (_instance == null)
{
Interlocked.CompareExchange(ref _instance, new Singleton(), null);
}
return _instance;
}
}
public void DoStuff() { }
}
EDIT: the test for thread-safety failed, can anyone explain why? How come Interlocked.CompareExchange isn't truly atomic?
public class Program
{
static void Main(string[] args)
{
Parallel.For(0, 1000000, delegate(int i) { Singleton.Instance.DoStuff(); });
}
}
Result (4 cores, 4 logical processors)
Instance created
Instance created
Instance created
Instance created
Instance created

If your singleton is ever in danger of initializing itself multiple times, you have a lot worse problems. Why not just use:
public class Singleton
{
private static Singleton instance=new Singleton();
private Singleton() {}
public static Singleton Instance{get{return instance;}}
}
Absolutely thread-safe in regards to initialization.
Edit: in case I wasn't clear, your code is horribly wrong. Both the if check and the new are not thread-safe! You need to use a proper singleton class.

You may well be creating multiple instances, but these will get garbage collected because they are not used anywhere. In no case does the static _instance field variable change its value more than once, the single time that it goes from null to a valid value. Hence consumers of this code will only ever see the same instance, despite the fact that multiple instances have been created.
Lock free programming
Joe Duffy, in his book entitled Concurrent Programming on Windows actually analyses this very pattern that you are trying to use on chapter 10, Memory models and Lock Freedom, page 526.
He refers to this pattern as a Lazy initialization of a relaxed reference:
public class LazyInitRelaxedRef<T> where T : class
{
private volatile T m_value;
private Func<T> m_factory;
public LazyInitRelaxedRef(Func<T> factory) { m_factory = factory; }
public T Value
{
get
{
if (m_value == null)
Interlocked.CompareExchange(ref m_value, m_factory(), null);
return m_value;
}
}
/// <summary>
/// An alternative version of the above Value accessor that disposes
/// of garbage if it loses the race to publish a new value. (Page 527.)
/// </summary>
public T ValueWithDisposalOfGarbage
{
get
{
if (m_value == null)
{
T obj = m_factory();
if (Interlocked.CompareExchange(ref m_value, obj, null) != null && obj is IDisposable)
((IDisposable)obj).Dispose();
}
return m_value;
}
}
}
As we can see, in the above sample methods are lock free at the price of creating throw-away objects. In any case the Value property will not change for consumers of such an API.
Balancing Trade-offs
Lock Freedom comes at a price and is a matter of choosing your trade-offs carefully. In this case the price of lock freedom is that you have to create instances of objects that you are not going to use. This may be an acceptable price to pay since you know that by being lock free, there is a lower risk of deadlocks and also thread contention.
In this particular instance however, the semantics of a singleton are in essence to Create a single instance of an object, so I would much rather opt for Lazy<T> as #Centro has quoted in his answer.
Nevertheless, it still begs the question, when should we use Interlocked.CompareExchange? I liked your example, it is quite thought provoking and many people are very quick to diss it as wrong when it is not horribly wrong as #Blindy quotes.
It all boils down to whether you have calculated the tradeoffs and decided:
How important is it that you produce one and only one instance?
How important is it to be lock free?
As long as you are aware of the trade-offs and make it a conscious decision to create new objects for the benefit of being lock free, then your example could also be an acceptable answer.

In order not to use 'double-checked locking mambo-jambo' or simply not to implement an own singleton reinventing the wheel, use a ready solution included into .NET 4.0 - Lazy<T>.

public class Singleton
{
private static Singleton _instance = new Singleton();
private Singleton() {}
public static Singleton Instance
{
get
{
return _instance;
}
}
}

I am not convinced you can completely trust that. Yes, Interlocked.CompareExchanger is atomic, but new Singleton() is in not going to be atomic in any non-trivial case. Since it would have to evaluated before exchanging values, this would not be a thread-safe implementation in general.

what about this?
public sealed class Singleton
{
Singleton()
{
}
public static Singleton Instance
{
get
{
return Nested.instance;
}
}
class Nested
{
// Explicit static constructor to tell C# compiler
// not to mark type as beforefieldinit
static Nested()
{
}
internal static readonly Singleton instance = new Singleton();
}
}
It's the fifth version on this page:
http://www.yoda.arachsys.com/csharp/singleton.html
I'm not sure, but the author seems to think its both thread-safe and lazy loading.

Your singleton initializer is behaving exactly as it should. See Raymond Chen's Lock-free algorithms: The singleton constructor:
This is a double-check lock, but without the locking. Instead of taking lock when doing the initial construction, we just let it be a free-for-all over who gets to create the object. If five threads all reach this code at the same time, sure, let's create five objects. After everybody creates what they think is the winning object, they called Interlocked­Compare­Exchange­Pointer­Release to attempt to update the global pointer.
This technique is suitable when it's okay to let multiple threads try to create the singleton (and have all the losers destroy their copy). If creating the singleton is expensive or has unwanted side-effects, then you don't want to use the free-for-all algorithm.
Each thread creates the object; as it thinks nobody has created it yet. But then during the InterlockedCompareExchange, only one thread will really be able to set the global singleton.
Bonus reading
One-Time Initialization helper functions save you from having to write all this code yourself. They deal with all the synchronization and memory barrier issues, and support both the one-person-gets-to-initialize and the free-for-all-initialization models.
A lazy initialization primitive for .NET provides a C# version of the same.

This is not thread-safe.
You would need a lock to hold the if() and the Interlocked.CompareExchange() together, and then you wouldn't need the CompareExchange anymore.

You still have the issue that you're quite possibly creating and throwing away instances of your singleton. When you execute Interlocked.CompareExchange(), the Singleton constructor will always be executed, regardless of whether the assignment will succeed. So you're no better off (or worse off, IMHO) than if you said:
if ( _instance == null )
{
lock(latch)
{
_instance = new Singleton() ;
}
}
Better performance vis-a-vis thread contention than if you swapped the position of the lock and the test for null, but at the risk of an extra instance being constructed.

An obvious singleton implementation for .NET?

Auto-Property initialization (C# 6.0) does not seem to cause the multiple instantiations of Singleton you are seeing.
public class Singleton
{
static public Singleton Instance { get; } = new Singleton();
private Singleton();
}

I think the simplest way after .NET 4.0 is using System.Lazy<T>:
public class Singleton
{
private static readonly Lazy<Singleton> lazy = new Lazy<Singleton>(() => new Singleton());
public static Singleton Instance { get { return lazy.Value; } }
private Singleton() { }
}
Jon Skeet has a nice article here that covers a lot of ways of implementing singleton and the problems of each one.

Don't use locking. Use your language environment
Mostly simple Thread-safe implementation is:
public class Singleton
{
private static readonly Singleton _instance;
private Singleton() { }
static Singleton()
{
_instance = new Singleton();
}
public static Singleton Instance
{
get { return _instance; }
}
}

Using statement in every function -> convert to class field with proper cleanup?

Basically I have a few functions that look like this:
class MyClass
{
void foo()
{
using (SomeHelper helper = CreateHelper())
{
// Do some stuff with the helper
}
}
void bar()
{
using (SomeHelper helper = CreateHelper())
{
// Do some stuff with the helper
}
}
}
Under the assumption I can use the same resource instead of a different one [instance] in every function is it ok practice in regard to cleanup and such to do this?:
class MyClass
{
SomeHelper helper = CreateHelper();
// ...foo and bar that now just use the class helper....
~MyClass()
{
helper.Dispose();
}
}

No, do not add a destructor (Finalizer).
You can reuse the resource but then your class has to implement IDisposable.
sealed class MyClass : IDisposable
{
SomeHelper helper = CreateHelper();
// ...foo and bar that now just use the class helper....
//~MyClass()
public void Dispose()
{
helper.Dispose();
}
}
And now you have to use MyClass instances in a using block. It self has become a managed resource .
A destructor is of no use, whenever a MyClass instance is being collected the associated helper object will also be in the same collection. But having a destructor still incurs considerable overhead.
The standard pattern for IDisposable uses a virtual void Dispose(bool disposing) method but when making the class sealed you can use the minimalistic implementation above.

In .NET you don't know when (or whether) finalizer is called at all.
Instead, explicitly indicate that your class is to be disposed of by implementing IDisposable:
(This is exactly what SomeHelper does)
class MyClass : IDisposable
{
readonly SomeHelper helper = CreateHelper();
// any method can use helper
public void Dispose()
{
helper.Dispose();
}
}
using(var myObj = new MyClass()) {
// at the end, myObj.Dispose() will trigger helper.Dispose()
}
I used readonly to ensure helper doesn't get re-assigned somewhere else in the class, but this really doesn't matter if you're careful.
You must be extra careful to never set it to null, or your Dispose will throw an exception. If the field is protected, you can check for nullity before calling Dispose on it so you know you're playing safe.

You can share such a resource during the lifetime of your object, in which case it is recommended that you implement IDisposable.

No, it is not. You don't know when the finalized will un. Also, if your resource is managed, it will be disposed of at some point without the finalized.
If you don't want to use using all the time, perhaps ou can use it once around many functions.

You don't need to override the finalizer in your object, which you have shown in your second code sample by ~MyClass().
You will need to implement the IDisposable pattern. You haven't been explicit in your question if you are using managed and unmanaged resources, but here's a quick sample for a managed resource. Stackoverflow has a myriad of examples on this. Reed Copsey also has a good series on it, and you can start here.
class MyClass : IDisposable
{
private bool _Disposed;
private SomeHelper _Helper;
protected virtual void Dispose()
{
this.Dispose(true);
}
public void Dispose(bool disposing)
{
if (_!Disposed && disposing)
{
if (_Helper != null)
_Helper.Dispose();
_Disposed = true;
}
}
}

The convention is that if your class owns an IDisposable object it should also implement IDisposable. So rather than implementing a finalizer your class should implement IDisposable and dipose of the helper there.
One problem with implementing the finalizer is that you have no control over when it's being called. The disposable pattern gives you a more deterministic way of cleaning up resources.

ReaderWriterLockSlim extension with Action

Consider the following extensions:
public static class ReaderWriteExt
{
public static void ExecWriteAction(this ReaderWriterLockSlim rwlock, Action action)
{
rwlock.EnterWriteLock();
try
{
action();
}
finally
{
rwlock.ExitWriteLock();
}
}
public static void ExecUpgradeableReadAction(this ReaderWriterLockSlim rwlock, Action action)
{
rwlock.EnterUpgradeableReadLock();
try
{
action();
}
finally
{
rwlock.ExitUpgradeableReadLock();
}
}
}
Also consider the following sample usage (stripped of some supporting code):
private static ReaderWriterLockSlim _rwlock = new ReaderWriterLockSlim();
private static ... _cacheEntries = ....;
public static void RemoveEntry(string name)
{
WeakReference outValue = null;
_rwlock.ExecUpgradeableReadAction(() =>
{
if (_cacheEntries.TryGetValue(name, out outValue))
{
if (!outValue.IsAlive)
{
_rwlock.ExecWriteAction(() => _cacheEntries.Remove(name));
}
}
});
}
I'm new to C# coding and I was unable to find enough information about these topics that could guide me. To my question: I am considering using this concept in our production code, is it a bad idea? What can go wrong?

That seems fine to me except that the code looks very cumbersome
I would probably implement IDisposable as:
public class WriteLock : IDisposable
{
ReaderWriterLockSlim _rwlock;
public WriteLock(ReaderWriterLockSlim rwlock )
{
_rwlock = rwlock;
_rwlock.EnterWriteLock();
}
public void Dispose()
{
_rwlock.ExitWriteLock();
}
}
Usage:
private ReaderWriterLockSlim _rwlock = new ReaderWriterLockSlim();
//...
using (new WriteLock(_rwlock)) //<-- here the constructor calls EnterWriteLock
{
_cacheEntries.Remove(name);
} //<---here Dispose method gets called automatically which calls ExitWriteLock
Similarly, you can implement UpgradeableReadLock class implementing IDisposable interface.
The idea is that you can create an instance of disposable class in using construct which ensures that in the constructor you enter into write lock by calling EnterWriteLock() method, and when it goes out of scope, Dispose() method is called automatically (by CLR) which calls ExitWriteLock() method.
Note that it will not dispose ReaderWriterLockSlim object; it will dispose WriteLock object which is just a wrapper. ReaderWriterLockSlim will be as such in the user-class.

I am not seeing any reason why that would not work safely. However, I have a suspicion that it will actually be slower than using a plain old lock. The reason is because ReaderWriterLockSlim has about 2x the overhead as compared to a lock.1 So you would you need the execution of the code in the critical section to consume a sufficient enough number of CPU cycles to overcome this added overhead just to reach the breakeven point. If all you are doing is simply accessing a Dictionary (or whatever data structure _cacheEntries happens to be) then I doubt RWLS is right for the situation. Reader-writer locks tend to work better in scenarios where the number of readers significantly outnumbers the writers and when the guarded section of code is long and drawn out. Obviously you should do your own benchmark tests because mileage will vary considerably depending on a lot of other factors. The degrees of parallelism and the number of cores in the hardware could give you more throughput using RWLS even though a simple breakeven point analysis did not favor them initially.
1Based on my own tests. ReaderWriterLock had about 5x the overhead.

Yes, there are technical reasons why this is not a good idea. If the Action throws an exception when updating the data, then the data is now in an unknown and very likely corrupt state. Your code unconditionally releases the writer lock, meaning that other threads are now accessing the partially-updated shared state. This is a recipe for disaster.

Question on IDisposable

My question is why do I need IDisposable? I have a class that consumes some resources
that need to be freed. I have two options
Without IDisposable
class SomeUtilityClass
{
public Stop()
{
// free resources
}
}
With IDisposable
class SomeUtilityClass, IDisposable
{
public void Dispose()
{
// free resources
}
}
So why do I need IDisposable here? It does not matther how to name the function.
class Program
{
public Main(..)
{
SomeUtilityClass _class = new SomeUtilityClass();
// clean up when we've done
_class.Stop();
// OR
_class.Dispose();
}
}

Because IDisposable is supported by C# and you can use cool using syntax:
using (IDisposable someDisposable = new ...)
{
// your code with someDisposable
}
This is actually transformed by compiler to something like:
IDisposable someDisposable = new ...
IDisposable someDisposable2 = someDisposable ;
try
{
// your code with someDisposable
}
finally
{
if (someDisposable2 != null)
{
someDisposable2.Dispose();
}
}
So if any exception happens inside using block your object would be disposed anyway.

You should only really use IDisposable when your class consumes unmanaged resources, and they need to be freed immediately (streams, db etc).
It also provides a way for the CLR to 'clean up' when there are unhandled exceptions that cause your thread to be unloaded.
Calling IDisposable marks the object as being available for garbage collection immediately, but if not implemented correctly you can cause your object to be promoted a garbage collection generation which can cause memory pressure (refer to Jeffery Richters CLR via c# 3 if you want a full explanation).
a quick google turned this up:
http://kleahy-technical.blogspot.com/2009/01/idisposable-and-garbage-collection.html
i suggest you read into the IDisposable pattern, when to use it, when not to and its implications on GC and state.
EDIT:
there is loads of info on stackoverflow too:
Use of Garbage Collection?

Well in your case, there is not much point implementing IDisposable, since you can manually dispose of your resources.
A common use of IDisposable is when you expose an interface that handles data connections, and you want all derived classes to dispose when they're done.
Consider this:
public interface IDataCtx
{
void CallDB();
}
public class MyDataCtx : IDataCtx
{
private SqlConnection dc;
public MyDataCtx() { dc = new SqlConnection(); dc.Open(); }
public void CallDB();
{
dc.Something();
}
}
Allowing you to do something like this:
IDataCtx ctx = new MyDataCtx();
ctx.CallDB();
But wait, what about that open connection? Uh oh!
If you made IDataCtx : IDisposable (and implemented the code in your derived ctx), you could do this:
IDataCtx ctx;
using (ctx = new MyDataCtx())
{
ctx.CallDB();
}
Guaranteeing that whatever implementation of IDataCtx you use, it will always be disposed of (even in the case of an exception).
That's how i use it anyway. (plus it's just good practice).

IDisposable interacts with the using keyword to make it easy to clean up after yourself, e.g.:
using (var file = new FileStream(...))
{
file.Write(...);
}
In the above code, the FileStream is closed as soon as the using block completes, rather than waiting around to be garbage-collected.

It's a convention used in the C# language.
You also get the nifty using statement to your disposal.
using (SomeUtilityClass _class = new SomeUtilityClass()) {
} // Dispose is automatically called

As well as being able to use the using statement, it also give the garbage collector a hint that the object can be removed from memory.

If your class owns unmanaged resources or your class owns managed IDisposable resources you should in generel implement the IDisposable interface.
An easy readable little article on when to implement IDisposable and Finalizers can be found here: http://nitoprograms.blogspot.com/2009/08/how-to-implement-idisposable-and.html