Ayende @ Rahien

Jonathan Oliver commented on Challenge: Why is this wrong?

Tue, 20 Oct 2009 02:36:35 GMT

ThreadStatic does not get along well when operating in a web environment because IIS may not necessarily start and end your request on the same thread: [www.hanselman.com/.../...pContextCurrentItems.aspx](http://www.hanselman.com/blog/ATaleOfTwoTechniquesTheThreadStaticAttributeAndSystemWebHttpContextCurrentItems.aspx)

Tobin Harris commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 23:31:06 GMT

In many cases it's more flexible to use a container for specifying lifecycle, rather than hard coding the desired one-instance-per-thread singleton behaviour. That could allow the component to be adapted and tested in different contexts (web, for example). Other than that, the "subsequent threads will have nulls" problem raised by @qbik is obvioiusly a serious issue :)

jocke commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 19:44:40 GMT

msdn.microsoft.com/en-us/library/system.threadstaticattribute.aspx "Do not specify initial values for fields marked with because such initialization occurs only once, when the class constructor executes, and therefore affects only one thread. If you do not specify an initial value, you can rely on the field being initialized to its default value if it is a value type, or to null if it is a reference typ". [http://www.yoda.arachsys.com/csharp/singleton.html](http://www.yoda.arachsys.com/csharp/singleton.html) "Typically a requirement of singletons is that they are created lazily - i.e. that the instance isn't created until it is first needed." Personally I think that the semantic fault is the worst, it can't be a singleton if it would (potentially) be initialized one time for each thread accessing it! Greetings from sweden /jocke

Josh commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 19:20:35 GMT

Just realized I left off my Factory although you should be able to figure I meant it to be: public class Factory { [ThreadStatic] public static readonly object mySingleton = new object(); }

Josh commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 19:18:31 GMT

Does this code even compile? By using the Readonly attribute you are saying MySingleton will only be assigned within the field initializer, once that's done it won't be assigned again. Since this field is marked as thread static the field initilizer will only run once when the object is first created. So if you try and access the field from other threads you'd get a null reference exception. Worse yet because its readonly you'd be unable to assign a new value to it. Take the following code: [MTAThread] static void Main(string[] args) { run(); Thread t = new Thread(new ThreadStart(run)); t.Start(); t.Join(); Console.Read(); } static void run() { if (Factory.mySingleton == null) { Console.WriteLine("SingleTon is null"); } else { Console.WriteLine("Singleton is not null"); } } If you run this you will find it's null when called from a new thread. Now if you try and assign it a value in the run method when it's null, the code will no longer compile because of the read only attribute. So you end up with a null field you can only access from a single thread, which would be the thread the static field initalizer ran on.

Alun Harford commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 16:12:22 GMT

This will return null for all threads that didn't call the static initializer (ie. all but one). That's probably not what you wanted.

tihobrazov commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 13:51:01 GMT

I guess because we don't know how CreateSingleInstance is implemented :)

Luis Abreu commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 13:41:58 GMT

I think that code will only run initialization once (for the 1st thread that access the value). The correct approach would be to wrap the field in a property which checks for null before returning a reference to that field.

Sergey commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 13:09:10 GMT

ThreadStaticAttribute indicates that the value of a static field is unique for _each_ thread.

Stijn Guillemyn commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 09:21:45 GMT

First off, I think a singleton should always be one single instance, not an instance per thread. If you want a single instance per thread, you shouldn't call it a singleton, but threadInstance of something like that. Secondly, this code will cause pain. Certainly if you're not executing on the first thread, as stated above, the only thread were the variable would be initialized. Thinking of it, would this thread always be the UI thread? Or is this conclusion a bridge too far? If true, code that depends on your 'singleton' instance would then have UI thread affinity? So a null reference check could be used as a check if you're on the UI thread? :) Or am I wrong about this?

Mikael Svenson commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 06:27:30 GMT

qbik got it spot on. I made this mistake myself in early .net days. It pays to think and read the manual every now and then :)

Krzysztof Kozmic commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 05:59:58 GMT

It'll get initialized only on the 1st thread so you'll get NullReferenceException on subsequent threads.

Diego Mijelshon commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 02:21:27 GMT

Well, qbik basically nailed it, so there's not a lot to say. I might add that calling "singleton" something that will (should) actually have one instance per thread is a semantic mistake. Rule of thumb is, never make a ThreadStatic readonly and never initialize inline. Instead, use an accessor that checks for null.

Dmitriy Nagirnyak commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 02:00:47 GMT

If CreateSingleInstance will fail mySingleton will be NULL which I doubt is the expected value of it.

Mohamed Meligy commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 01:07:43 GMT

You'd use ThreadStatic so that you have only one MySingleton in every thread (by default MySingleton should be only one instance for all threads, using ThreadStatic you have N MySingleton for N threads). The problem is that the assignment to a static field (to "CreateSingleInstance()" return value) is just the same as if it was written inside a static constructor, and a static constructor is called only once, so, the second thread and beyond will not call it, meaning will NOT assign MySingleton a value, and it will remain to default(MySingleton), null.

Nick Berardi commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 00:53:10 GMT

I think qbik has nailed it.

Philip commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 00:42:53 GMT

Bad because 0) Little known - in a asp.net web call, the actual thread used can actually change during the asp.net event processing. use context instead. 1) initialization only on the first thread 2) any threadpool threads will possibly be reused and hence the "thread-specific singleton" will behave oddly. 3) It's *magic*!

John Simons commented on Challenge: Why is this wrong?

Mon, 19 Oct 2009 00:12:30 GMT

Because the ThreadPool reuses threads. Specially bad in web scenarios, because the web pipeline uses the ThreadPool to handle requests.

alberto commented on Challenge: Why is this wrong?

Sun, 18 Oct 2009 23:29:13 GMT

Because different threads will have different instances of the field, so it's not a Singleton anymore, AND only one of the threads will be properly initialized with a MySingleton type, the others will be null. PD: A free *Rhino Mocks* license? Is it the "Ultimate" version or what? :D

Bill Barry commented on Challenge: Why is this wrong?

Sun, 18 Oct 2009 23:04:10 GMT

While I dislike the usage of the tread static attribute in general, This case in particular you seem to be suggesting you want a singleton but here you will not have a singleton. In place of the thread static attribute, I like to use the following pattern (which I also use for accessing cache and session): public class Memoize { public static T Execute

Dmitry commented on Challenge: Why is this wrong?

Sun, 18 Oct 2009 22:09:01 GMT

The initializer will run only once during appdomain initialization, not on every thread.

Thilak Nathen commented on Challenge: Why is this wrong?

Sun, 18 Oct 2009 22:00:54 GMT

Darn!

Frank commented on Challenge: Why is this wrong?

Sun, 18 Oct 2009 21:42:32 GMT

Initialization of ThreadStatic variables only happen once. So on other threads the value will be the default value, being null for reference types.

Ayende Rahien commented on Challenge: Why is this wrong?

Sun, 18 Oct 2009 21:40:51 GMT

Thilak, That is actually a bug in my post about a bug :-) Fixed, thanks for spotting this.

Thilak Nathen commented on Challenge: Why is this wrong?

Sun, 18 Oct 2009 21:26:28 GMT

... or should I say, no variable type.

Thilak Nathen commented on Challenge: Why is this wrong?

Sun, 18 Oct 2009 21:25:18 GMT

No return type?

qbik commented on Challenge: Why is this wrong?

Sun, 18 Oct 2009 21:10:18 GMT

hmm, maybe this is the reason: "Note: Do not specify initial values for fields marked with ThreadStaticAttribute, because such initialization occurs only once, when the class constructor executes, and therefore affects only one thread. If you do not specify an initial value, you can rely on the field being initialized to its default value if it is a value type, or to a null reference (Nothing in Visual Basic) if it is a reference type." (MSDN) So you would have correct instance for the first thread that access the singleton, and null's for all other threads. And the readonly flag stops you from initializing the field in any other place.