We Keep Coding

Static initializers vs static constructors, execution orders, release mode behaving oddly

I've read several of the other posts here about this, but my problem seems to fly in the face of the general wisdom posted here (Is the order of static class initialization in C# deterministic?) and several related posts.
I've got an ASP.Net 4.0 application, and my Application_Start() method runs through touching a lot of things to get them set up. One of those things is initializing our db connection string for our DAL, others initializing other variables. A couple of days ago our release builds started blowing up, and after adding a lot of debug logging, the cause turned out to be a new static initizalizer being called before Application_Start() was officially entered and trying to access our DAL before it was initialized. And this seems to run afoul of what I see in other posts here about the order of execution for static constructors and initializers.
Specifically, the static initializers are not being run at the point in the code where they are called; the stack traces in the release build indicate that release compilation shuffles them up to be part of entering Application_Startup(). In other words the stack trace when it blows up shows Application_Startup() on the stack - but no line number associated with it. The stack trace for the DAL initialization does show the line number.
To flesh out some pseudo code, we have
Application_Start()
{
DAL.Inst.GetSetting("ConnectionString"); // tickles the singleton to get the DAL initialized.
// numerous other lines of code
if (!AppUtil.IsAdminAccountSetup)
{ // Do admin account setup
}
// More code
}
public class DAL
{
private static DAL _singleton;
static DAL()
{
_singleton = new DAL();
_singleton.Initialize();
}
public static DAL Inst
{
get { return _singleton; }
}
// all the other methods
}
public class AppUtil
{
private static bool _isAdminSetup = InitializeAdminSetup();
public static bool IsAdminAccountSetup
{
get { return _isAdminSetup; }
}
private static bool InitializeAdminSetup()
{
// Call DAL for query
}
private static bool _isProductRegistered = InitializeProdReg();
public static bool IsProductRegistered
{
get { return _isProductRegistered; }
}
private static bool InitializeProdReg()
{
// Call DAL for query
}
}
AppUtil recently had the IsProductRegistered boolean added, and that seems to be when things headed south.
AppUtil.IsProductRegistered is not called in Application_Start(), but when we look at stack traces about the order of queries to the DAL, we see the initializer for AppUtil.IsProductRegistered calling the DAL (before DAL.Inst gets touched) and from Application_Start() (no line number).
Then we see the connection string getting initialized as part of the DAL static constructor, and that traces back to the DAL.Inst reference in Application_Start() - and here it does show the line number.
If we change both of the static initialzers in AppUtil to a single static constructor, things go back to being initialized in reference order and the blow-up goes away.
But the whole situation flies in the face of what I've read about what .Net says it will do.
Sorry for the information barf, but I hoped to have enough detail to make the conundrum clear.

There is a big difference between initializers on a class with a static constructor and without. On classes without a static constructor they can run at any time prior to the first access, much earlier if the runtime so decides. With a static constructor they can only run immediately prior to the first access.
DAL has a static constructor so it's guaranteed to initialize on first access and no earlier.
AppUtil has no static constructor, so it can run as early as it likes, in particular it can run before you initialized DAL.
Your immediate problem should disappear if you add a static constructor to AppUtil even if it's empty.
You should read C# and beforefieldinit by Jon Skeet, where he explains this difference in detail.
To quote the specification:
If a static constructor (§10.12) exists in the class, execution of the static field initializers occurs immediately prior to executing that static constructor. Otherwise, the static field initializers are executed at an implementation-dependent time prior to the first use of a static field of that class.
The static constructor for a closed class type executes at most once in a given application domain. The execution of a static constructor is triggered by the first of the following events to occur within an application domain:
An instance of the class type is created.
Any of the static members of the class type are referenced.
Still this kind of initialization pattern is a bad idea on many levels. These initializers are hard to debug, can change their order on a whim.
You should not use static fields for this kind of state in the first place. Create a single instance of these classes during your initialization code instead of using a classic singleton which uses state from outside its own class to initialize. Or even better, use proper Dependency Injection. These kind of services is the place where DI and IoC shine.

In addition to Loki's comments.
You are potentially going to burnt very badly if dependant on statics in a DAL. eg Entity framework.
Do not attempt this without understanding the .Net ASP pipeline and how threads are used.
You must consider what is going on in the app pool. The lifetime of the app pool. Thread safety. The app pool allocates incoming calls to threads. So you must make the statics thread safe.
You may need a custom initializer that gets called for every request no just on APP start.
As you are discovering app start could already have run on a previous request.
for your consideration:
//Global asax handlers
public override void Init() {
base.Init();
// handlers managed by ASP.Net during Forms authentication
BeginRequest += new EventHandler(BeginRequestHandler);
// PostAuthorizeRequest += new EventHandler(PostAuthHandler);
EndRequest += new EventHandler(EndRequestHandler);
}
Consider
ASP.NET controller constructors that "renew" contexts left over from last call.
Consider how you will protect your static. // thread safe ????
private static Object _bgalock = new Object();
[ThreadStatic] // thread based static to avoid disasters....
private static sometypeStaticUsedGlobally _ouch;
// Then Get and Set static with lock

Locking a private static object

I am wondering which following code is best:
private static volatile OrderedDictionary _instance;
private static readonly Object SyncLock = new Object();
private static OrderedDictionary Instance
{
get { return _instance ?? (_instance = new OrderedDictionary()); }
}
public static Mea Add(Double pre, Double rec)
{
lock (SyncLock)
{
...
}
}
Or is it OK and better IMO just use the following?
private static volatile OrderedDictionary _instance;
private static OrderedDictionary Instance
{
get { return _instance ?? (_instance = new OrderedDictionary()); }
}
public static Mea Add(Double pre, Double rec)
{
lock (Instance)
{
...
}
}
Based on Mike Strobel's answer I have done to following changes:
public static class Meas
{
private static readonly OrderedDictionary Instance = new OrderedDictionary();
private static readonly Object SyncLock = new Object();
public static Mea Add(Double pre, Double rec)
{
lock (SyncLock)
{
Instance.Add(pre, rec);
...
}
}
}

Mike Strobel's advice is good advice. To sum up:
Lock only objects that are specifically intended to be locks.
Those lock objects should be private readonly fields that are initialized in their declarations.
Do not try to roll your own threadsafe lazy initialization. Use the Lazy<T> type; it was designed by experts who know what they are doing.
Lock all accesses to the protected variable.
Violate these sensible guidelines when both of the following two conditions are true: (1) you have a empirically demonstrated customer-impacting performance problem and solid proof that going with a more complex low-lock thread safety system is the only reasonable solution to the problem, and (2) you are a leading expert on the implications of processor optimizations on low-lock code. For example, if you are Grant Morrison or Joe Duffy.

The two pieces of code are not equivalent. The former ensures that all threads will always use the same lock object. The latter locks a lazily-initialized object, and there is absolutely nothing preventing multiple instantiations of your _instance dictionary, resulting in contents being lost.
What is the purpose of the lock? Does the serve a purpose other than to guarantee single-initialization of the dictionary? Ignoring that it fails to accomplish this in the second example, if that is its sole intended purpose, then you may consider simply using the Lazy<T> class or a double-check locking pattern.
But since this is a static member (and does not appear to capture outer generic parameters), it will presumably only be instantiated once per AppDomain. In that case, just mark it as readonly and initialize it in the declaration. You're probably not saving much this way.
Since you are concerned with best practices: you should never use the lock construct on a mutable value; this goes for both static and instance fields, as well as locals. It is especially bad practice to lock on a volatile field, as the presence of that keyword indicates that you expect the underlying value to change. If you're going to lock on a field, it should almost always be a readonly field. It's also considered bad practice to lock on a method result; that applies to properties too, as properties are effectively a pair of specially-named accessor methods.

If you do not expose the Instance to other classes, the second approach is okay (but not equivalent). It's best practice to keep the lock object private to the class that is using it as a lock object. Only if other classes can also take this object as lock object you may run into issues.
(For completeness and regarding #Scott Chamberlain comment:)
This assumes that the class of Instance is not using lock (this) which contrary represents bad practice.
Nevertheless, the property could make problems. The null coalescing operator is compiled to a null check + assignment... Therefore you could run into race conditions. You might want to read more about this. But also consider to remove the lazy initialization at all, if possible.

rationale behind lock inside lock?

I am reviewing an example code in a book and came across the following code(simplified).
In the code, when Subscribe(T subscriber) is called, the thread enters into a lock section.
and then, when code inside the lock calls AddToSubscribers(T subscriber) method, the method has another lock. why is this second lock necessary?
public abstract class SubscriptionManager<T> where T : class
{
private static List<T> subscribers;
private static void AddToSubscribers(T subscriber)
{
lock (typeof(SubscriptionManager<T>))
{
if (subscribers.Contains(subscriber))
return;
subscribers.Add(subscriber);
}
}
public void Subscribe(T subscriber)
{
lock (typeof(SubscriptionManager<T>))
{
AddToSubscribers(subscriber);
}
}
}

In that context, it isn't; however, since locks are re-entrant that can be useful to ensure that any other caller of AddToSubscribers observes the lock. Actually, for that reason I'd say "remove it from Subscribe and just let AddToSubscribers do the locking".
However! A lock on a Type is pretty dangerous. A field would be safer:
// assuming static is correct
private static readonly object syncLock = new object();
and lock(syncLock). Depending on when subscribers is assigned, you might also get away with lock(subscribers) (and no extra field).
I should also note that having an instance method add to static state is pretty.... unusual; IMO Subscribe should be a static method, since it has nothing to do with the current instance.

In the code you posted, it isn't necessary. But then again, the code you posted is incomplete - for example the subscribers list is never initialized.
Locking on typeof(SubscriptionManager) is probably not a good idea either - locking on the subscribers field would be better - but would require the subscribers field to be initialized, e.g.
private static List<T> subscribers = new List<T>();

You probably should read near that sample and see what book talks about.
For that particular case - no, second lock is unnecessary.
Note: The sample is dangerous since it locks on public object (type). Normally one locks on special private object so external code is not able to mistakenly introduce deadlocks by mistakenly locking on the same object.

I also faced a situation once where I had to use nested Lock.
My case was, the function of the second lock maybe called from elsewhere, since it was a static function. However, for your case it won't be necessary since each data member belongs to an Instance and not static..

Static method and threads

I have put one question on MSDN forum but got two opposite answers. In general I am intersted how threading works with static classes. If my code calls this(below) static method from 10 threads at the same time, is it thread safe? I mean, how the code flows behind the scenes? Does every thread executes the code within itself (like I think it does with non-static classes) or it is different with static method and, because its static, all threads try to reach the code and collide? Thanks!
public static class A
{
static void Method(object parameter)
{
SqlCeConnection = .....
}
}
Link to MSDN question: Here
PS: I am sorry due to IE page errors I cannot click on "Add comment" or "Answer", Jon Skeet answer is good (as usually :)

It's exactly the same as with non-static classes. Being static doesn't affect anything really - except that static methods are generally expected to be thread-safe. They're not automatically thread-safe, but you should make sure that you implement them in a thread-safe manner.
If the code doesn't use any shared state, it should be fine. And yes, without any locking, all the threads can be executing the same method concurrently.

A nice example can be singleton pattern.In this all you need is a single instance for a given class and that can be made sure by making the constructor private and giving a static method or property to access the instance.Following code snippets highlight the same :-
class MyClass
{
private MyClass()
{
}
public static MyClass Instance
{
get
{
lock(typeof(MyClass))
{
if(__instance == null)
__instance = new MyClass();
}
return __instance;
}
}
}
Since the "Instance" method is marked static(thread consistent access) , but in multi threaded envoirnment you need to manully take care of it(using lock).

How to make a method exclusive in a multithreaded context?

I have a method which should be executed in an exclusive fashion. Basically, it's a multi threaded application where the method is invoked periodically by a timer, but which could also be manually triggered by a user action.
Let's take an example :
The timer elapses, so the method is
called. The task could take a few
seconds.
Right after, the user clicks on some
button, which should trigger the
same task : BAM. It does nothing
since the method is already running.
I used the following solution :
public void DoRecurentJob()
{
if(!Monitor.TryEnter(this.lockObject))
{
return;
}
try
{
// Do work
}
finally
{
Monitor.Exit(this.lockObject);
}
}
Where lockObject is declared like that:
private readonly object lockObject = new object();
Edit : There will be only one instance of the object which holds this method, so I updated the lock object to be non-static.
Is there a better way to do that ? Or maybe this one is just wrong for any reason ?

This looks reasonable if you are just interested in not having the method run in parallel. There's nothing to stop it from running immediately after each other, say that you pushed the button half a microsecond after the timer executed the Monitor.Exit().
And having the lock object as readonly static also make sense.

You could also use Mutex or Semaphore if you want it to work cross process (with a slight performance penalty), or if you need to set any other number than one of allowed simultaneous threads running your piece of code.
There are other signalling constructs that would work, but your example looks like it does the trick, and in a simple and straightforward manner.

Minor nit: if the lockObject variable is static, then "this.lockObject" shouldn't compile. It also feels slightly odd (and should at least be heavily documented) that although this is an instance method, it has distinctly type-wide behaviour as well. Possibly make it a static method which takes an instance as the parameter?
Does it actually use the instance data? If not, make it static. If it does, you should at least return a boolean to say whether or not you did the work with the instance - I find it hard to imagine a situation where I want some work done with a particular piece of data, but I don't care if that work isn't performed because some similar work was being performed with a different piece of data.
I think it should work, but it does feel a little odd. I'm not generally a fan of using manual locking, just because it's so easy to get wrong - but this does look okay. (You need to consider asynchronous exceptions between the "if" and the "try" but I suspect they won't be a problem - I can't remember the exact guarantees made by the CLR.)

I think Microsoft recommends using the lock statement, instead of using the Monitor class directly. It gives a cleaner layout and ensures the lock is released in all circumstances.
public class MyClass
{
// Used as a lock context
private readonly object myLock = new object();
public void DoSomeWork()
{
lock (myLock)
{
// Critical code section
}
}
}
If your application requires the lock to span all instances of MyClass you can define the lock context as a static field:
private static readonly object myLock = new object();

The code is fine, but would agree with changing the method to be static as it conveys intention better. It feels odd that all instances of a class have a method between them that runs synchronously, yet that method isn't static.
Remember you can always have the static syncronous method to be protected or private, leaving it visible only to the instances of the class.
public class MyClass
{
public void AccessResource()
{
OneAtATime(this);
}
private static void OneAtATime(MyClass instance)
{
if( !Monitor.TryEnter(lockObject) )
// ...

This is a good solution although I'm not really happy with the static lock. Right now you're not waiting for the lock so you won't get into trouble with deadlocks. But making locks too visible can easily get you in to trouble the next time you have to edit this code. Also this isn't a very scalable solution.
I usually try to make all the resources I try to protect from being accessed by multiple threads private instance variables of a class and then have a lock as a private instance variable too. That way you can instantiate multiple objects if you need to scale.

A more declarative way of doing this is using the MethodImplOptions.Synchronized specifier on the method to which you wish to synchronize access:
[MethodImpl(MethodImplOptions.Synchronized)]
public void OneAtATime() { }
However, this method is discouraged for several reasons, most of which can be found here and here. I'm posting this so you won't feel tempted to use it. In Java, synchronized is a keyword, so it may come up when reviewing threading patterns.

We have a similar requirement, with the added requirement that if the long-running process is requested again, it should enqueue to perform another cycle after the current cycle is complete. It's similar to this:
https://codereview.stackexchange.com/questions/16150/singleton-task-running-using-tasks-await-peer-review-challenge
private queued = false;
private running = false;
private object thislock = new object();
void Enqueue() {
queued = true;
while (Dequeue()) {
try {
// do work
} finally {
running = false;
}
}
}
bool Dequeue() {
lock (thislock) {
if (running || !queued) {
return false;
}
else
{
queued = false;
running = true;
return true;
}
}
}