Please look at the following code:
public sealed class Foo<T> : IDisposable
where T : IDisposable, new()
{
public T Bar
{
get { return _bar; }
}
public void Reset()
{
var oldBar = _bar;
using (oldBar)
{
_bar = new T();
}
}
public void Dispose()
{
// TODO:
}
private T _bar = new T();
}
Consider multithreaded environment. Bar getter and Reset method are being called from multiple threads. Is it guaranteed that client would never get a disposed T object via Bar property? Foo object is guaranteed not to be disposed at that moment. If not, how to get it right? I want to use low-lock techniques if possible.
Thank you in advance.
UPDATE
Thank you all guys for the help. The question need to be clarified. I want
Foo to manage Bar state;
to be sure that clients will not use disposed T object.
It seems that it is impossible with the code provided before. Here is the code that reflects my needs:
public sealed class Foo<T> : IDisposable
where T : class, IDisposable, new()
{
public bool TryExecute(Action<T> action)
{
lock (_sync)
{
if (_bar == null)
{
return false;
}
action(_bar);
return true;
}
}
public void Reset()
{
lock (_sync)
{
if (_bar == null)
{
throw new ObjectDisposedException(string.Empty);
}
Reset(new T());
}
}
public void Dispose()
{
lock (_sync)
{
if (_bar != null)
{
Reset(null);
}
}
}
private void Reset(T newBar)
{
var oldBar = _bar;
using (oldBar)
{
_bar = newBar;
}
}
private T _bar = new T();
private readonly object _sync = new object();
}
I beleive it is thread safe this time.
You can't get all of the requirements, but at least you can make Reset itself thread-safe without locks. As it is, it can fail because multiple concurrent calls could try to dispose the same object.
You can't prevent clients from storing a reference to a previous T instance.
What you can do, is ensure that only one Reset call can change the stored value at a time, using Interlocked.CompareExchange. This would also allow one of the calls to dispose the old value. The original code would fail because all concurrent calls could attempt to dispose the same old value. With CompareExchange we can swap new and old values atomically :
public void Reset()
{
var originalValue=_bar;
var replaced=Interlocked.CompareExchange(ref _bar,new T(),originalValue);
if(replaced!=_bar)
{
//We got to replace the value,
//we could dispose it safely if we wanted to
if (replaced!=null)
{
replaced.Dispose();
}
}
}
The comparison to oldValue means that even if two threads execute Reset concurrently, only one of them will be allowed to assign to _bar and be able to dispose the old value. The other will see that _bar has a new value.
This doesn't solve the problem of multiple temporary objects and anyway, we don't want to dispose.
It would be easier if Reset accepted a parameter with the replacement value so it didn't have to create the new objects itself.
public void Reset(T newValue)
{
var originalValue=_bar;
var replaced=Interlocked.CompareExchange(ref _bar,newValue,originalValue);
...
}
I would say use _bar variable via Bar property only, do not use it directly. Put a lock on set property on Bar. Code as follows:
public sealed class Foo<T> : IDisposable
where T : IDisposable, new()
{
private readOnly object key;
public Foo(){
key = new Object();
this.Bar = new T();
}
public T Bar
{
get { return _bar; }
private set {
lock(key){
_bar = value;
}
}
}
public void Reset()
{
var oldBar = _bar;
this.Bar = new T();
}
public void Dispose()
{
this.Bar = null;
}
private T _bar;
}
Related
My question is really an extension to this SO question about testing a property is null before returning it. I have a similar situation:
public class MyClass
{
private readonly string _Name { get; set; }
private readonly IEnumerable<T> _Values { get; set; }
private IEnumerable<T> _MyProp { get; private set; }
public IEnumerable<T> MyProp
{
get
{
if(_MyProp == null)
{
this.SetProp();
}
return this._MyProp;
}
private set;
}
public MyClass(string Name, IEnumerable<T> Values)
{
this._Name = Name;
this._Values = Values;
}
private void SetProp()
{
// Business logic using Name and Values
this._MyProp = resultOfLogic;
}
}
The accepted answer to the linked SO question mentions that this is not a thread safe way of doing it. Can someone advise why it isn't and if there's a way to do this in a thread safe manner?
If another thread is running, this thread can call SetProp() between the test and the call to SetProp() on your thread.
I use code like this, to make it more safe:
// Dedicated object to lock for this property only
private object myPropSync = new object();
private T _myPropVal;
public IEnumerable<T> MyProp
{
get
{
// Check if property is null
if(_myPropVal== null)
{
// If null -> make sure you are the only one in the next section
lock (myPropSync) {
// Re-test, because another thread can
// set the property while waiting for the lock
if (_myPropVal== null) {
this.SetProp();
}
}
}
return this._myPropVal;
}
private set {
lock (_myPropSync) {
_myPropVal = value;
}
}
}
Can someone advise why
Imagine, that there are two threads, which execute get_MyProp in parallel.
Then it is possible to get this sequence:
T1 : _MyProp == null -> true
T2 : _MyProp == null -> true
T1 : this.SetProp(); -> _MyProp is initialized
T2 : this.SetProp(); -> T2 rewrites _MyProp value, that was calculated by T1
if there's a way to do this in a thread safe manner
Convert SetProp to return IEnumerable<T> instead of setting field, and use Lazy<T> (by default, initialization will be thread-safe):
private IEnumerable<T> CalcProp()
{
// Business logic using Name and Values
return resultOfLogic;
}
public IEnumerable<T> MyProp
{
get { return _MyProp.Value; }
}
private readonly Lazy<IEnumerable<T>> _MyProp;
public MyClass(string Name, IEnumerable<T> Values)
{
this._Name = Name;
this._Values = Values;
this._MyProp = new Lazy<IEnumerable<T>>(CalcProp);
}
I think there may be an error in the code you posted. The fragment
public IEnumerable<T> MyProp
{
get
{
if(MyProp == null)
{ // ...
is infinitely recursive and will cause a stack overflow (uncapitalised!).
Did you mean the last line to use _Values as a backing field and test that for null instead of MyProp?
I have an object that only initializes itself with barebones data when constructed (fast), and loads itself for real (slow) when first accessed. The idea is that I'm creating a lot of these barebones objects at startup and hash them into a map, then fully load each object whenever it is individually accessed for the first time. The problem is that I cannot guarantee how clients will interact with this object, there are multiple public methods that might be invoked.
Is there a good pattern to support this kind of situation? The obvious (and my current) solution is to track state with an internal bool, check against that bool in every function that might be invoked, and load that way. But that requires code duplication of that behavior across all public functions, and is vulnerable to errors.
I can imagine a single point-of-entry method that then dishes out behaviors based on a client request type etc., but before I go consider going down that road I want to see if there's a commonly accepted approach/pattern that I might not be aware of. I'm doing this in C#, but any insight is appreciated.
If I understood what you want to achieve, you are looking for the Proxy Design Pattern, more specifically, a virtual Proxy.
Refer to http://www.dofactory.com/net/proxy-design-pattern
A small example would be something like:
public abstract class IObjectProvider
{
public abstract IObjectProvider Object{get;}
public abstract void doStuff();
}
public class RealObject : IObjectProvider
{
public RealObject()
{
//Do very complicated and time taking stuff;
}
public override IObjectProvider Object
{
get { return this; }
}
public override void doStuff()
{
//do this stuff that these objects normally do
}
}
public class ObjectProxy : IObjectProvider
{
private IObjectProvider objectInstance = null;
public override IObjectProvider Object
{
get
{
if (objectInstance == null)
objectInstance = new RealObject();
return objectInstance;
}
}
public override void doStuff()
{
if(objectInstance!=null)
objectInstance.doStuff();
}
}
public class SkeletonClass
{
public IObjectProvider Proxy1 = new ObjectProxy();
public IObjectProvider Proxy2 = new ObjectProxy();
}
static void Main(String[] args)
{
//Objects Not Loaded
SkeletonClass skeleton = new SkeletonClass();
//Proxy1 loads object1 on demand
skeleton.Proxy1.Object.doStuff();
//Proxy2 not loaded object2 until someone needs it
}
Here's an example of dynamic proxy approach.
using System;
using System.Diagnostics;
using Castle.DynamicProxy; //Remember to include a reference, too. It's nugettable package is Castle.Core
namespace ConsoleApp
{
public class ActualClass
{
//Have static instances of two below for performance
private static ProxyGenerator pg = new ProxyGenerator();
private static ActualClassInterceptor interceptor = new ActualClassInterceptor();
//This is how we get ActualClass items that are wrapped in the Dynamic Proxy
public static ActualClass getActualClassInstance()
{
ActualClass instance = new ActualClass();
return pg.CreateClassProxyWithTarget<ActualClass>(instance, interceptor);
}
//Tracking whether init has been called
private bool initialized = false;
//Will be used as evidence of true initialization, i.e. no longer null
private int? someValue = null;
public void Initialize()
{
if (!initialized)
{
//do some initialization here.
someValue = -1; //Will only get set to non-null if we've run this line.
initialized = true;
}
}
//Any methods you want to intercept need to be virtual!
public virtual int replaceValue(int value)
{
//below will blow up, if someValue has not been set to -1 via Initialize();
int oldValue = someValue.Value;
someValue = value;
return oldValue;
}
//block off constructor from public to enforce use of getActualClassInstance
protected ActualClass() { }
}
public class ActualClassInterceptor : ActualClass, IInterceptor
{
public void Intercept(IInvocation invocation)
{
//Call initialize before proceeding to call the intercepted method
//Worth noting that this is the only place we actually call Initialize()
((ActualClass)invocation.InvocationTarget).Initialize();
invocation.Proceed();
}
}
class Program
{
static void Main(string[] args)
{
ActualClass instance1 = ActualClass.getActualClassInstance();
ActualClass instance2 = ActualClass.getActualClassInstance();
int x1 = instance1.replaceValue(41);
int x2 = instance2.replaceValue(42);
int y1 = instance1.replaceValue(82);
Debug.Assert(y1 == 41);
int y2 = instance2.replaceValue(84);
Debug.Assert(y2 == 42);
var read = Console.ReadKey();
}
}
}
Please consider the following code
public class DataModel
{
public int a { get; set; }
}
public static class StaticAccess
{
private static _Data = new DataModel();
private static DataModel Data {
lock(_Data) {
return _Data;
}
}
}
Will an access to property a such us StaticAccess.Data.a = 3; will lock for the entire property value assignment or just for the _Data static field reference retrieval?
In other words, can I use the above implementation to synchronize the access to the properties of the underlying data model or do I have to implement the lock in every single property of it?
e.g.
public class DataModel
{
private int _a;
public int a {
get {
lock(this) {
return _a;
}
}
set {
lock(this) {
_a = value;
}
}
}
Thanks in advance.
The code in your first example will synchronize access to the instance of DataModel in the StaticAccess class (i.e.: to the _Data field), not to members of the instance of DataModel itself. For that you need your second example.
Side note: Avoid locking on this, and use a dedicated object to lock on, as you don't know who else might lock on the instance. Use something like
public class DataModel
{
private readonly object _lock= new object();
private int _a;
public int a {
get {
lock(_lock) {
return _a;
}
}
set {
lock(_lock) {
_a = value;
}
}
}
Edit based on comments:
The Data property of StaticAccess returns the instance of DataModel. So only thread at a time can obtain the reference to that instance. The goal, however, is to synchronize access to DataModel.a. Since access to DataModel.a is not synchronized any code that tries to either read or write to DataModel.a is not synchronized meaning that multiple threads accessing StaticAccess.Data.a is not synchronized:
void ThreadProc1()
{
// (might) block on "get StaticAccess.Data"
// will not block on "DataModel.a = 20"
StaticAccess.Data.a = 20;
}
void ThreadProc2()
{
// (might) block on "StaticAccess.Data"
// will not block on "DataModel.a = 10"
StaticAccess.Data.a = 10;
// (might) block on "StaticAccess.Data"
// will not block on "DataModel.a"
// "StaticAccess.Data.a" might be 10 or 20;
Console.WriteLine(StaticAccess.Data.a);
}
I would like to implement lazy loading on properties with PostSharp.
To make it short, instead of writing
SomeType _field = null;
private SomeType Field
{
get
{
if (_field == null)
{
_field = LongOperation();
}
return _field;
}
}
I would like to write
[LazyLoadAspect]
private object Field
{
get
{
return LongOperation();
}
}
So, I identify that I need to emit some code in the class to generate the backing field, as well as inside the getter method in order to implement the test.
With PostSharp, I was considering overriding CompileTimeInitialize, but I am missing the knowledge to get a handle over the compiled code.
EDIT:
The question can be extended to any parameterless method like:
SomeType _lazyLoadedField = null;
SomeType LazyLoadableMethod ()
{
if(_lazyLoadedField ==null)
{
// Long operations code...
_lazyLoadedField = someType;
}
return _lazyLoadedField ;
}
would become
[LazyLoad]
SomeType LazyLoadableMethod ()
{
// Long operations code...
return someType;
}
After our comments, I think I know what you want now.
[Serializable]
public class LazyLoadGetter : LocationInterceptionAspect, IInstanceScopedAspect
{
private object backing;
public override void OnGetValue(LocationInterceptionArgs args)
{
if (backing == null)
{
args.ProceedGetValue();
backing = args.Value;
}
args.Value = backing;
}
public object CreateInstance(AdviceArgs adviceArgs)
{
return this.MemberwiseClone();
}
public void RuntimeInitializeInstance()
{
}
}
Test code
public class test
{
[LazyLoadGetter]
public int MyProperty { get { return LongOperation(); } }
}
Thanks to DustinDavis's answer and comments, I could work on my own implementation, and I just wanted here to share it to help other people.
The main differences from the original answer are:
Implement the suggested "only run the operation once" (purpose of the lock)
Made the initialization status of the backing field more reliable by passing this responsibility to a boolean.
Here is the code:
[Serializable]
public class LazyLoadAttribute : LocationInterceptionAspect, IInstanceScopedAspect
{
// Concurrent accesses management
private readonly object _locker = new object();
// the backing field where the loaded value is stored the first time.
private object _backingField;
// More reliable than checking _backingField for null as the result of the loading could be null.
private bool _hasBeenLoaded = false;
public override void OnGetValue(LocationInterceptionArgs args)
{
if (_hasBeenLoaded)
{
// Job already done
args.Value = _backingField;
return;
}
lock (_locker)
{
// Once the lock passed, we must check if the aspect has been loaded meanwhile or not.
if (_hasBeenLoaded)
{
args.Value = _backingField;
return;
}
// First call to the getter => need to load it.
args.ProceedGetValue();
// Indicate that we Loaded it
_hasBeenLoaded = true;
// store the result.
_backingField = args.Value;
}
}
public object CreateInstance(AdviceArgs adviceArgs)
{
return MemberwiseClone();
}
public void RuntimeInitializeInstance() { }
}
I think the requirement cannot be accurately described as 'lazy loading', but is a special case of a more general caching aspect with in-AppDomain storage but without eviction. A general caching aspect would be able to handle method parameters.
When you use a ThreadLocal<T> and T implements IDisposable, how are you supposed to dispose of the members being held inside of the ThreadLocal?
According to ILSpy, the Dispose() and Dispose(bool) methods of ThreadLocal are
public void Dispose()
{
this.Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
int currentInstanceIndex = this.m_currentInstanceIndex;
if (currentInstanceIndex > -1 && Interlocked.CompareExchange(ref this.m_currentInstanceIndex, -1, currentInstanceIndex) == currentInstanceIndex)
{
ThreadLocal<T>.s_availableIndices.Push(currentInstanceIndex);
}
this.m_holder = null;
}
It does not appear that ThreadLocal attempts to call Dispose on its child members. I can't tell how to reference each thread it internally has allocated so I can take care of it.
I ran a test with the following code, the class is never disposed
static class Sandbox
{
static void Main()
{
ThreadLocal<TestClass> test = new ThreadLocal<TestClass>();
test.Value = new TestClass();
test.Dispose();
Console.Read();
}
}
class TestClass : IDisposable
{
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected void Dispose(bool Disposing)
{
Console.Write("I was disposed!");
}
}
I had a look at the code in ThreadLocal<T> to see what the current Dispose is doing and it appears to be a lot of voodoo. Obviously disposing of thread-related stuff.
But it doesn't dispose of the values if T itself is disposable.
Now, I have a solution - a ThreadLocalDisposables<T> class, but before I give the full definition it's worth thinking about what should happen if you wrote this code:
var tl = new ThreadLocalDisposables<IExpensiveDisposableResource>();
tl.Value = myEdr1;
tl.Value = myEdr2;
tl.Dispose();
Should both myEdr1 & myEdr2 both be disposed? Or just myEdr2? Or should myEdr1 be disposed when myEdr2 was assigned?
It's not clear to me what the semantics should be.
It is clear to me, however, that if I wrote this code:
var tl = new ThreadLocalDisposables<IExpensiveDisposableResource>(
() => new ExpensiveDisposableResource());
tl.Value.DoSomething();
tl.Dispose();
Then I would expect that the resource created by the factory for each thread should be disposed of.
So I'm not going to allow the direct assignment of the disposable value for ThreadLocalDisposables and only allow the factory constructor.
Here's ThreadLocalDisposables:
public class ThreadLocalDisposables<T> : IDisposable
where T : IDisposable
{
private ThreadLocal<T> _threadLocal = null;
private ConcurrentBag<T> _values = new ConcurrentBag<T>();
public ThreadLocalDisposables(Func<T> valueFactory)
{
_threadLocal = new ThreadLocal<T>(() =>
{
var value = valueFactory();
_values.Add(value);
return value;
});
}
public void Dispose()
{
_threadLocal.Dispose();
Array.ForEach(_values.ToArray(), t => t.Dispose());
}
public override string ToString()
{
return _threadLocal.ToString();
}
public bool IsValueCreated
{
get { return _threadLocal.IsValueCreated; }
}
public T Value
{
get { return _threadLocal.Value; }
}
}
Does this help?
In .NET 4.5, the Values property was added to ThreadLocal<> to deal with the problem of manually managing the lifetime of ThreadLocal objects. It returns a list of all current instances bound to that ThreadLocal variable.
An example using a Parallel.For loop accessing a ThreadLocal database connection pool was presented in this MSDN article. The relevant code snippet is below.
var threadDbConn = new ThreadLocal<MyDbConnection>(() => MyDbConnection.Open(), true);
try
{
Parallel.For(0, 10000, i =>
{
var inputData = threadDbConn.Value.GetData(i);
...
});
}
finally
{
foreach(var dbConn in threadDbConn.Values)
{
dbConn.Close();
}
}
Normally when you don't explicitly dispose of a class that holds an unmanaged resource, the garbage collector will eventually run and dispose of it. For this to happen, the class has to have a finalizer that disposes of its resource. Your sample class doesn't have a finalizer.
Now, to dispose of a class that's held inside a ThreadLocal<T> where T is IDisposable you also have to do it yourself. ThreadLocal<T> is just a wrapper, it won't attempt to guess what's the correct behavior for its wrapped reference when it is itself disposed. The class could, e.g., survive its thread local storage.
This is related to ThreadLocal<> and memory leak
My guess is because there is no IDisposable constraint on T, it is assumed that the user of ThreadLocal<T> will dispose of the local object, when appropriate.
How is the ThreadLocal.Dispose method itself getting called? I would expect that it would most likely be within something like a "using" block. I would suggest that one wrap the "using" block for the ThreadLocal with a "using" block for the resource that's going to be stored there.
MSDN reference states that the ThreadLocal values should be disposed by the thread using them once its done. However in some instances such as event threading using a thread pool A thread may use the value and go off to do something else and then come back to the value N number of times.
Specific example is where I want an Entity Framework DBContext to persist across the lifespan of a series of service bus worker threads.
I've written up the following class which I use in these instances:
Either DisposeThreadCompletedValues can be called manually every so often by another thread or the internal monitor thread can be activated
Hopefully this helps?
using System.Threading;
public class DisposableThreadLocal<T> : IDisposable
where T : IDisposable
{
public DisposableThreadLocal(Func<T> _ValueFactory)
{
Initialize(_ValueFactory, false, 1);
}
public DisposableThreadLocal(Func<T> _ValueFactory, bool CreateLocalWatcherThread, int _CheckEverySeconds)
{
Initialize(_ValueFactory, CreateLocalWatcherThread, _CheckEverySeconds);
}
private void Initialize(Func<T> _ValueFactory, bool CreateLocalWatcherThread, int _CheckEverySeconds)
{
m_ValueFactory = _ValueFactory;
m_CheckEverySeconds = _CheckEverySeconds * 1000;
if (CreateLocalWatcherThread)
{
System.Threading.ThreadStart WatcherThreadStart;
WatcherThreadStart = new ThreadStart(InternalMonitor);
WatcherThread = new Thread(WatcherThreadStart);
WatcherThread.Start();
}
}
private object SyncRoot = new object();
private Func<T> m_ValueFactory;
public Func<T> ValueFactory
{
get
{
return m_ValueFactory;
}
}
private Dictionary<Thread, T> m_InternalDict = new Dictionary<Thread, T>();
private Dictionary<Thread, T> InternalDict
{
get
{
return m_InternalDict;
}
}
public T Value
{
get
{
T Result;
lock(SyncRoot)
{
if (!InternalDict.TryGetValue(Thread.CurrentThread,out Result))
{
Result = ValueFactory.Invoke();
InternalDict.Add(Thread.CurrentThread, Result);
}
}
return Result;
}
set
{
lock (SyncRoot)
{
if (InternalDict.ContainsKey(Thread.CurrentThread))
{
InternalDict[Thread.CurrentThread] = value;
}
else
{
InternalDict.Add(Thread.CurrentThread, value);
}
}
}
}
public bool IsValueCreated
{
get
{
lock (SyncRoot)
{
return InternalDict.ContainsKey(Thread.CurrentThread);
}
}
}
public void DisposeThreadCompletedValues()
{
lock (SyncRoot)
{
List<Thread> CompletedThreads;
CompletedThreads = new List<Thread>();
foreach (Thread ThreadInstance in InternalDict.Keys)
{
if (!ThreadInstance.IsAlive)
{
CompletedThreads.Add(ThreadInstance);
}
}
foreach (Thread ThreadInstance in CompletedThreads)
{
InternalDict[ThreadInstance].Dispose();
InternalDict.Remove(ThreadInstance);
}
}
}
private int m_CheckEverySeconds;
private int CheckEverySeconds
{
get
{
return m_CheckEverySeconds;
}
}
private Thread WatcherThread;
private void InternalMonitor()
{
while (!IsDisposed)
{
System.Threading.Thread.Sleep(CheckEverySeconds);
DisposeThreadCompletedValues();
}
}
private bool IsDisposed = false;
public void Dispose()
{
if (!IsDisposed)
{
IsDisposed = true;
DoDispose();
}
}
private void DoDispose()
{
if (WatcherThread != null)
{
WatcherThread.Abort();
}
//InternalDict.Values.ToList().ForEach(Value => Value.Dispose());
foreach (T Value in InternalDict.Values)
{
Value.Dispose();
}
InternalDict.Clear();
m_InternalDict = null;
m_ValueFactory = null;
GC.SuppressFinalize(this);
}
}