|
|
|
No messages were posted in the selected interval. You might like to contact Administrator to start a new blog/thread/post. Or, try looking @
.Here is the last post:
|
|
Wednesday, July 16
|
Last night as I was installing software for a course, I grabbed Jeffrey Richter's new book, called CLR via C#. This is a follow-up to his last book, Applied Microsoft.NET Framework Programming, which is one of my all-time favorite books. The book looks similar in content and structure, but one can hopefully assume it has been updated for .NET 2.0 :) I haven't had a chance to dig into yet, so I can't be sure of all the differences and new content.
Singleton Design Pattern
As I thumbed through the book, I decided to read the section on Thread Synchronization, which talked about the Singleton Design Pattern and the ReaderWriterLock Class. The Singleton Design Pattern is one of those often talk about design patterns, but I rarely use it. The book mentions the famous Double-Check Locking Technique used for thread synchronization:
public sealed class Singleton
{
private static Singleton _instance;
private static object syncLock = new object();
private Singleton() {}
public static Singleton Instance {
get {
if (_instance == null) {
lock(syncLock) {
if (_instance == null)
{
_instance = new Singleton();
}
}
}
return _instance;
}
}
}
I changed up the code a bit on-the-fly from Jeffrey's example in the book and removed his comments, but this is essentially the famous double-check locking technique used to create singletons and assure thread synchronization.
I have been using a different technique where I instantiate the singleton in the class constructor, which is guaranteed to only run once and be thread safe. This eliminates all that locking code:
public sealed class Singleton
{
private static Singleton _instance;
static Singleton() {
_instance = new Singleton();
}
private Singleton() {}
public static Singleton Instance {
get {
return _instance;
}
}
}
It was cool to see that Jeffrey also prefers a variation of what I use. Basically the same code, he just eliminates the constructor call and instantiates the object directly, which is fine if you don't have any additional processing.
public sealed class Singleton
{
private static Singleton _instance = new Singleton();
private Singleton() {}
public static Singleton Instance {
get {
return _instance;
}
}
}
The advantage of the double-check locking technique is essentially lazy-loading. In the other methods, one doesn't know for sure when the class constructor will be called, only that it will be called before an object of the type is instantiated. Hence, the singleton instance could be instantiated even if the client doesn't request it. However, unless the singleton creation is memory and process intensive and there is a good chance it might not be used, this is hardly a big deal.
ReaderWriterLock Class
Jeffrey begins to talk about the ReaderWriterLock Class, which I have seen used but never used it myself. What was interesting, is that Jeffrey isn't too fond of this class. I think he likes the idea of it, but has a problem with its implementation. Here is a piece from the book:
“Normally, at this point in the book, I'd describe how to use this lock in your own applications; however, I just can't do that here because I don't recommend that anyone ever use it. As you will see, this class has many problems with its implementation.“ - CLR via C#, Richter, page 642.
Now my interest is peaked and I need to look into this class a bit more as I have seen entire MSDN Magazine articles on the ReaderWriterLock Class.
|
|
Post your own comment
|
|
0
comment(s):-
|
|
|
|
|
|
|
|
