Recently I was having some issues with a singelton class that was lazy initializing a dictionary where a second thread would try to use it before it had actually been populated. So I implemented the variable initialization through the Lazy<T> class.
Here is my code:
private static Dictionary<string, string> GroupDefaults
{
get { return mGroupDefaults.Value; }
}
private static Lazy<Dictionary<string, string>> mGroupDefaults =
new Lazy<Dictionary<string,string>>(delegate
{
Dictionary<string, string> defaults = new Dictionary<string, string>();
foreach (KeyValuePair<string, UnitGroup> groupDef in Groups)
defaults.Add(groupDef.Key, groupDef.Value.First().Key);
return defaults;
});
This fixed the problem and now I am considering making this a regular practice of mine to use the Lazy<T> class anywhere I do lazy initialization to avoid any possible threading issues. So basically I would like to know if this is good/common practice? Or will it be detremental to performance or something?
It's pretty hard to say without knowing what type of performance constraints you have, but in my experience, one-time initialization is rarely a bottleneck (since by definition it only occurs once.) Lazy<T> was written to provide you with this exact service, so I would recommend using it.
From the documentation, I find the following:
If no delegate is passed in the Lazy constructor,
the wrapped type is created by using Activator.CreateInstance when the value property is first accessed.
If the type does not have a default constructor, a run-time exception is thrown.
Activator.CreateInstance is a method that is notoriously bad for performance. However, that doesn't seem to be a problem in your case, and at any rate, as dlev said, invoking the method once wouldn't be a problem. I haven't seen Lazy<T> used very often, but I do not see any reason not to use it in your case.
If this is for a singleton, a static constructor might be what you want. Something like:
class MySingleton
{
static MySingleton()
{
Instance().InitDict();
}
}
I think you may be using Lazy for not it's intended use. Lazy is to be used for situations where something has a large initialization cost, but there is a probable chance that it may not be used during the lifetime of the object.
If you always call GroupDefaults at least once per it's lifetime a better method would be to initialize GroupDefaults in a background thread at the start of the container's lifetime and hope that it is done before it is done initializing (I know there is a class for this but I need to dig in to the MSDN to find it)
Related
Can someone please explain in simple words, why does Lazy in C# needs to get Func?
public Lazy (Func<T> valueFactory);
I understand that sometime you need a function in order to do some fancy init().
however, many times I find myself writing a singleton, or something simple, where just create a new instance of the class.
As shown in Jon's Skeet book.
http://csharpindepth.com/Articles/General/Singleton.aspx
I find this syntax to be very annoying.
Thanks!
private static readonly Lazy<Singleton> lazy =
new Lazy<Singleton>(() => new Singleton());
You need a func, because if you could do this:
var Lazy<Foo> = new Lazy<Foo>(new Foo());
You're already instantiating the Foo, which you don't want, otherwise you didn't have to use Lazy<T> to begin with.
The Func<T> holds the initializer for Foo, but only initializes it when you access the Lazy<T>'s Value.
You can't get the Lazy to work without the initializer function. That is how it ensures the logic for the creation of the object is there, but not yet called.
Consider this:
new Lazy<Singleton>(new Singleton());
This already instantiates a new Singleton. There is no use for the lazy any more. The function allows Lazy<T> to construct the object at any time in the future.
Another plus for the Func<T> is that it doesn't need to be a new object it instantiates. It can be anything else. It can be a multi-line statement, a fetch of something else, etc.
One optimization I could argue for is that new Lazy<T>() would use the new() on T, which prevents the need for you to call the constructor. That is however not possible with the current syntax, but it works with a static factory method.
Something like this (and yes, it is basically does what you do now, but then tucked away in the core):
public static class LazyDefault
{
public static Lazy<TNew> New<TNew>() where TNew : new()
{
return new Lazy<TNew>(() => new TNew());
}
}
Or as CodeCaster suggested with a derived class:
public class SuperLazy<T> : Lazy<T>
where T : new()
{
public SuperLazy()
: base(() => new T())
{
}
}
What you give to Lazy<T> constructor is known as a thunk (Wikipedia):
In computer programming, a thunk is a subroutine used to inject an
additional calculation into another subroutine. Thunks are primarily
used to delay a calculation until its result is needed, or to insert
operations at the beginning or end of the other subroutine. They have
a variety of other applications in compiler code generation and
modular programming.
That is, the core of lazy evalutation is that the whole thing to be evaluated is delayed until it's really required.
If you find annoying having to explicitly provide the Func<T>, you may simplify that in the following way:
public static class Lazy
{
public static Lazy<T> Of<T>()
where T : class, new() => new Lazy<T>(() => new T())
}
var lazyFoo = Lazy.Of<Foo>()
Lazy needs a Func to actually initialize the inner value. the whole purpose of using Lazy is initializing a value only when its needed. so there should be a way Lazy to actually initialize the value when needed, that's where the Func comes in. i don't see any other way to implement something like Lazy other than passing a initialization function.
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.
the page at http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html?page=5 says that code like this:
public final static Singleton INSTANCE = new Singleton();
automatically employs lazy instantiation.
I want to verify if
1) all compilers do this, or is it that the compiler is free to do whatever it wishes to
2) and since c# does not have the "final" keyword, what's the best way to translate this into c# (and at the same time it should automatically employ lazy instantiation too)
Yes. The static initializer is guaranteed to run before you are able to access that INSTANCE. There are two negatives with this approach:
If an error occurs within the Singleton's construction, then the error is a little harder to debug ("Error in initializer").
On first use of the class, that object will be instantiated. If you did the locking approach, then it would not be instantiated until it was needed. However, being that the example is a singleton, then this is not a problem at all, but it could be a drag on an unused, yet lazily instantiated piece of code elsewhere that is not a singleton.
The translation for C# is readonly instead of final.
In my opinion, this is still vastly preferable to the secondary approach (synchronized/locked, checked instantiation within the a static getter) because it does not require any synchronization code, which is faster, easier to read and just as easy to use.
// Member Variable
private static readonly object _syncLock = new object();
// Now inside a static method
foreach (var lazyObject in plugins)
{
if ((string)lazyObject.Metadata["key"] = "something")
{
lock (_syncLock)
{
// It seems the `IsValueCreated` is not up-to-date
if (!lazyObject.IsValueCreated)
lazyObject.value.DoSomething();
}
return lazyObject.value;
}
}
Here I need synchronized access per loop. There are many threads iterating this loop and based on the key they are looking for, a lazy instance is created and returned.
lazyObject should not be created more that one time. Although Lazy class is for doing so and despite of the used lock, under high threading I have more than one instance created (I track this with a Interlocked.Increment on a volatile static int and log it somewhere). The problem is I don't have access to definition of Lazy and MEF defines how the Lazy class create objects. I should notice the CompositionContainer has a thread-safe option in constructor which is already used.
My questions:
1) Why the lock doesn't work ?
2) Should I use an array of locks instead of one lock for performance improvement ?
Is the default constructor of T in your Lazy complex? MEF uses LazyThreadSafetyMode.PublicationOnly which means each thread accessing the unitialised Lazy will generate a new() on T until the first to complete the initialisation. That value is then returned for all threads currently accessing .Value and their own new() instances are discarded. If your constructor is complex (perhaps doing too much?) you should redefine it as doing minimal construction work and moving configuration to another method.
You need to think about the method as a whole. Should you consider:
public IPlugin GetPlugin(string key)
{
mutex.WaitOne();
try
{
var plugin = plugins
.Where(l => l.Metadata["key"] == key)
.Select(l => l.Value);
.FirstOrDefault();
return plugin;
}
finally
{
mutex.ReleaseMutex();
}
}
You also need to consider that if plugins is not read-only then you need to synchronise access to that instance too, otherwise it may be modified on another thread, causing your code to fall over.
There is a specific constructor of Lazy<T, TMetadata> for such scenarios, where you define a LazyThreadSafetyMode when constructing a Lazy instance... Otherwise, the lock might not work for many different reasons, e.g. if this is not the only place where the Value property of this Lazy<T> instance is ever accessed.
Btw you got I typo in the if statement...
While reading Jon Skeet's article on singletons in C# I started wondering why we need lazy initialization in a first place. It seems like the fourth approach from the article should be sufficient, here it is for reference purposes:
public sealed class Singleton
{
static readonly Singleton instance=new Singleton();
// Explicit static constructor to tell C# compiler
// not to mark type as beforefieldinit
static Singleton()
{
}
Singleton()
{
}
public static Singleton Instance
{
get
{
return instance;
}
}
}
In the rare circumstances, where you have other static methods on a singleton, lazy initialization may have benefits, but this is not a good design.
So can people enlighten me why lazy initialization is such a hot thing?
In those scenarios where whatever it is you are initializing might not be needed at all, and is expensive to initialize, (in terms of CPU cycles or resources), then implementing a lazy initializor saves that cost in those cases where the object is not required.
If the object will always be required, or is relatively cheap to initialize, then there is no added benefit from a lazy initializer.
In any event, implementing a lazy initializer improperly can make a singleton non-thread-safe, so if you need this pattern, be careful to do it correctly. Jon's article has a pattern, (I think it's the last one), that addresses this issue.
You don't need lazy initialization on a singleton, if the only reason you're going to use that type is to reference the instance.
If, however, you reference any other property or method on the type, or the type itself, you will initialize the singleton.
Granted, good design would leave one task for one type, so this shouldn't be a problem. If you make your singleton class to "complex", however, lazy initialization can help keep you from having consequences due to initializing too soon.
I'm not sure that this applies to C# as well, but I'll answer for C++:
One of the ideas behind Singletons is that the order of initialization of static objects is undefined. So if you have a static class that tries to use another static class, you might be in trouble.
A concrete example: Let's say I have a Log class, which I decided to implement as a Singleton. Let's also assume I have a method called LoadDB, which for whatever reason, is a static called at the start of the program. Assuming LoadDB decides it needs to log something, it will call the Singleton. But since the order of static initialization is undefined, it might be doing something that's an error.
A Singleton fixes this, since once you call GetInstance(), no matter where you are in the initialization process, the object is guaranteed to exist.
Again, I don't know if this is relevant, but at least that's the history of it (as far as I remember).
From Java DI perspective, lazy initialization is good, there are always (say, spring) beans in another API that you might not want to use, for example, an eagerly loaded singleton cache (something that is shared with everyone using the cache) might not be needed for you although it may be referred as a dependency in your same code. Whats the point in loading the singleton wasting resources?
The lazy initialization implementation choice is tricky, in spring, would you choose lazy-init="true" (spring eagerly instantiates singletons), an init-method/destroy-method, #PostConstruct, InitializingBean - afterPropertiesSet() method or return same spring instance in a getInstance() method?
The choice is a tradeoff of testability over reusability outside the spring container.