I have a simple class which has a static constructor and a instance constructor. Now when i initialized the class , both static and instance constructor are called. Only static is referred once in a application domain . Can i again call the same class initialization and static constructor initialize again? I have tried but it didn't happen? Is there any way we can call static constructor again in main() method after using garbage collection on the class.
Here is the code:
public class Employee
{
public Employee()
{
Console.WriteLine("Instance constructor called");
}
static Employee()
{
Console.WriteLine("Static constructor called");
}
~Employee()
{
//Dispose();
}
}
Now in main method call:
static void Main(string[] args)
{
Employee emp = new Employee();
Employee emp = new Employee();
}
Output:
Static constructor called
Instance constructor called
Instance constructor called
Now the static didn't called again. Because it is called once in application domain. But is their any way we could call it again without unloading application domain. Can we use GC class over here?
Thanks.
Pal
Unless you prod it with reflection, the static constructor (or more generally, the type initializer) is only executed once per concrete class, per AppDomain.
Note that for generics, using different type arguments you'll get different concrete classes:
public class Foo<T>
{
Foo()
{
Console.WriteLine("T={0}", typeof(T));
}
public static void DummyMethod() {}
}
...
Foo<int>.DummyMethod(); // Executes static constructor first
Foo<string>.DummyMethod(); // Executes static constructor first
Foo<string>.DummyMethod(); // Type is already initialized; no more output
Not possible. The CLR keeps an internal status bit that tracks whether the type initializer was started. It cannot run again. That status bit is indeed stored in the loader heap as part of the AppDomain state. The workaround is simple, just add a static method to the class.
The point of a constructor is to put things into a desired initial valid state.
An instance constructor puts an instance into an initial valid state.
An instance constructor that takes arguments puts an instance into a initial valid state that reflects its arguments.
A static constructor puts the type into an initial valid state. E.g. initialising static members used by the class' static methods or shared by all instances.
Ideally all methods will leave the object and the type in a valid state, but constructors differ in being responsible for getting it into one in the first place.
Any attempt to call a constructor twice is therefore a mistake, since "put it into an initial valid state again" isn't something you can logically do twice ("initial" and "again" don't work well in the same clause). We are helped by the compiler (in it refusing to compile) and the language (in there being no way to express this) from doing such a thing.
And, being a logical impossibility it isn't something you can actually want to do (well, I can want to draw a triangle with more than 3 sides, but only to say that I did). This suggests that you are using your constructor to do something other than setting up an initial valid state.
Doing anything other than establishing such a valid state in a constructor is (as is failing to do so) at best an optimisation, quite often a serious design flaw and quite possibly (worse of all because it goes unfixed longer) an attempted optimisation that is really a serious design flaw.
One sign that your attempt at an optimisation is really a design flaw is a desire to call a static constructor more than once, or to call an instance constructor more than once on the same object.
Identify the desired repeatable behaviour, move it into a separate method, and have it called as needed from both the constructor and elsewhere. Then double check your design's logic, as this is quite a serious mistake to find in a class design and suggests you've got deeper problems.
Related
Problem:
Class1.foo1 relies on Class2.foo2, but it can't be guaranteed they'll compile in an order that will allow class2.foo2 to have been initialized when referenced by Class1.foo1.
class Class1
{
static Foo foo1 = new Foo("arg1", Class2.foo2);
}
class Class2
{
static Foo foo2 = new Foo("arg2");
}
Since Class2.foo2 has not be initialized when Class1.foo1 is created, the 'Class2.foo2' argument passed is simply null.
My Question:
Is there a known pattern to handle this sort of reliance scenario that doesn't require verbose initializers to be written for every field? I can throw as much code into the Foo class as needed to make it work because it only runs once at the beginning of the program, I'd just really like to keep it hidden away, because a great number of these fields need to be written.
What I've Read:
I've come across a few threads talking about lazy initialization which almost sounds appropriate in that it does something the first time an object is needed, and it's field specific, but it results in unwieldy code:
static Foo _otherFoo;
static Foo otherFoo
{
get
{
if (_otherFoo == null)
return new Foo("arg2");
else return _otherFoo;
}
}
I'd like to save my fellow developers from carpal tunnel. It wouldn't be a problem if all this bloat could be hidden behind a constructor:
public Foo(params Foo[] dependencies)
{
if(anyItem in dependencies) == null
anyItem = new Foo("Params are defined per-instance in the initializer. What goes here?");
}
But I can't know Class2.foo2's initialization parameters. Since this only runs once at startup, I decided to look into reflection as an option, but from what I've seen, reflection can't help you discern anything about a field's initializer, you can only get its value after it's been initialized.
It looks like the order of class initialization is determined by the order fields are accessed:
Is the order of static class initialization in C# deterministic?
So I ran some tests to see how this plays out, and it doesn't seem to halt initialization of fields in order to intialize their dependencies i.e. Class1.foo1's constructor must fully complete before Class2.foo2 gets initialized, which means Class2.foo2 will remain null.
My Question (again):
Is there a known pattern to handle this sort of reliance scenario that doesn't require verbose initializers to be written for every field?
Is there any way to query the .NET runtime to determine whether an object has finished its construction, or if the construction is still on-going and/or was aborted with an exception?
Basically, something equivalent to:
class Foo {
public string ConstructionState { get; private set; }
public Foo() {
try {
ConstructionState = "ongoing";
// ... do actual constructor stuff here ...
ConstructionState = "completed";
}
catch (Exception) {
ConstructionState = "aborted";
throw;
}
}
}
... except also taking into account field initializers, base class constructors etc., and without needing to modify the constructor.
A well-behaved object should never expose itself until it's fully constructed. If a partially constructed object is leaked, you're already violating that contract.
The runtime doesn't care, of course. There's nothing special about a partially-constructed object as far as the runtime is concerned - it's still subject to the same memory constraints, finalization and garbage collection as a fully constructed object.
If you own the object, the solution is simple - don't leak the object during construction. The usual way to do some global change during object initialisation is to use a static method (or a factory) instead of a constructor. If you don't own the object, you're pretty much out of luck.
The runtime specification doesn't explicitly say there's no way to check if an object is partially constructed, but it doesn't say there is either (as far as I can tell) - so even if you found some way, it wouldn't be safe to rely on it. Inspecting by hand shows that .NET object headers have no such information, and a disassembly of the constructor shows there's no non-user code after a constructor finishes that could update such a state.
The runtime does store a few flags in "weird" places. The mark & sweep garbage collector in desktop MS.NET stores its marks in an "unused" bit of the pointer to the virtual method table, for example. But as far as the runtime is concerned, the object is "done" even before any of its constructors run - all of that is handled during the allocation in newobj, before the constructor (a special instance method) runs. The object header (which also contains the object size) and virtual method table (so the object is of the most derived type even before the constructors run) are already set here, and all the memory directly used by that instance is already allocated (and pre-zeroed - so you don't get pointers to random bits of memory). This means that memory safety isn't impacted by partially-constructed objects as far as the runtime is concerned.
The main difference between a constructor and another instance method is that the constructor must only ever be called once on any instance. On the CIL level, this is enforced simply by the fact that you can't invoke the constructor directly - you only ever use newobj, which pushes the constructed object on the stack. Just like with other instance methods, it doesn't track if a particular method finishes or not - after all, it's perfectly legal to have a method that never finishes, and you can actually do the same thing with a (non-static) constructor.
If you want a proof that the runtime doesn't care, I present to you... the object can be collected by the GC before the constructor even finishes:
class Test
{
public static WeakReference<Test> someInstance;
public static void AliveTest()
{
Test t;
if (someInstance == null) Console.WriteLine("Null");
else Console.WriteLine(someInstance.TryGetTarget(out t));
}
public Test()
{
someInstance = new WeakReference<Test>(this);
AliveTest();
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
AliveTest();
}
}
class Program
{
static void Main(string[] args)
{
Test t = new Test();
Test.AliveTest();
Console.ReadLine();
}
}
This test program writes out True, False, False (make sure to run it in Release mode and without the debugger - .NET prevents many things like this to make debugging easier). The object has been collected before its constructor even finished, which means that there's no special treatment for constructors in this regard. Another reason not to use the "constructor updates something static" pattern, and especially not the "finalizer updates it back". If you add a finalizer to this sample code, it will run before the constructor finishes. Ouch.
Even your solution would be insufficient in the general case. To cite CLI specification:
It is explicitly not a requirement that a conforming implementation of the CLI guarantee that all state updates performed within a constructor be uniformly visible before the constructor completes.
There's no guarantee another thread would have correct information about the construction state.
For bonus points, it also doesn't help if the object isn't sealed. A derived classes constructor would run after the base class constructor and in C# there's no way to rewrite this to encompass all the constructors that normally run in a sequence. The best you could do is maintain a separate "constructed state" for each constructor, which is confusing at best (and breaks a few OOP principles - it would require all consumers of the object to know of all possible types the object could have).
I have a class Meterage which I expect to be instantiated several times, probably in quick succession. Each class will need to know the location of the dropbox folder in the executing machine, and I have code for this.
The class currently has a variable:
private string dropboxPath = string.Empty;
to hold the path, but I am considering making this a static to save repeated execution of
this.LocateDropboxFolder();
in the constructor. But I am a little concerned by the switch: what if two constructors try to set this at the same time? Would this code in the constructor be safe (LocateDropboxFolder becomes static too in this example):
public Meterage()
{
if (dropboxPath == string.Empty)
{
LocateDropboxFolder();
}
}
I think my concerns are perhaps irrelevant as long as I don't have construction occurring in multiple threads?
If the field is made static then static field initializers or static constructors are the easy way to initialize them. This will be executed at most once in a thread safe manner.
private static string dropboxPath;
static Meterage()
{
LocateDropboxFolder();
}
If you don't want to re-assign the field I suggest you to use readonly modifier, then the code should look like:
private static readonly string dropboxPath;
static Meterage()
{
dropboxPath = LocateDropboxFolder();
}
LocateDropboxFolder needs to return a string in this case.
Variables declared outside the constructor are evaluated before the constructor. Then the constructor will evaluate it.
Do remember that you will end up have only one dropBoxPath. If this is intended, it is okay to do so. Optionally, make LocateDropboxFolder a static method and call it from the static constructor.
If you want to prevent other constructors to overwrite the default, try this:
if (string.IsNullOrEmpty(dropboxPath))
{
LocateDropboxFolder();
}
Or, in a static constructor (at most called once):
static Meterage()
{
LocateDropboxFolder();
}
private static LocateDropboxFolder()
{
...
}
Your example will be safe provided your code is executing synchronously. If multiple instances are created, their constructors will be called in the order they are created.
On the first run through, LocateDropboxFolder() will execute. When this completes, dropboxPath will be set.
On the second constructor execution, LocateDropboxFolder() will not execute because dropboxPath will no longer equal string.Empty (provided 'LocateDropboxFolder()' does not return string.Empty.
However, if LocateDropboxFolder() is asynchronous or the objects are instantiated on different threads, then it is possible to create a second Meterage instance before dropBoxPath has been set by the LocateDropboxFolder() function. As such, multiple calls to the function will likely be made.
If you wish to guard against multithreading errors like this, you could consider using lock statements.
You might potentially end up running the LocateDropboxFolder multiple times if the object tries to be constructed multiple times in close succession from multiple threads. As long as the method returns the same result every time though this shouldn't be a problem since it will still be using the same value.
Additionally if you are setting the value of dropboxPath in the constructor then there is no point setting a default value for it. I'd just declare it (and not assign it) and then check for null in your constructor.
I hava a feeling that your Meterage class is breaking a Single Responsibility Principle. What has the meterage to do with a file access? I would say you have 2 concerns here: your Meterage and, let's say, FolderLocator. the second one should have some property or method like Dropbox which could use lazy evaluation pattern. It should be instantiated once and this single instance can be injected to each Metarage instance.
Maybe not FolderLocator but FileSystem with some more methods than just a single property? Nos sure what you're actually doing. Anyway - make an interface for this. That would allow unit testing without using the actual Dropbox folder.
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
Exactly what happens when Foo.SomeCheck() is called in the Bar class? Is an instance of Foo created in order to call SomeCheck()? If so, is this instance stored on the heap, and is it ever collected through garbage collection?
public class Foo() {
public static bool SomeCheck() {
return true;
}
}
public class Bar() {
public void SomeMethod() {
// what happens when we access Foo to call SomeCheck?
if (Foo.SomeCheck()) {
//do something
}
}
}
Static methods differ from instance methods in that no instance of the class they belong to needs to have been created for them to be called. When you call a static method, you in fact make the call using the name of the type rather than an instance of the type - which should reinforce the idea that static methods are not called on instances. That bears repeating and emphasis: No instance of a class is required to call a public static method of that class.
Now, your example is malformed, but presumably, the line: if( Foo.SomeCheck() ) is calling the SomeCheck static method using the name of the type: Foo - not an instance. Bar however, has to be instantiated in order to make this call - however, in your example, you don't have a well-formed instance of Bar. Code generally has to exist inside a method (or a member initializer) - which you don't have here.
To respond to the other parts of your question. Assuming the code in question is part of an instance method, something has to instantiate Bar - and invoke that method. That something would have to create or otherwise acquire an instance of Bar. Reference types will always be creted on the heap - but that's largely irrelevant here.
As for garbage collection, you normally shouldn't worry about this. The .NET runtime makes sure to cleanup instances that are not referenced from any root object in your program. Roots are typically instances that reside somewhere on the callstack or are referenced by static members of one type or another. Since we don't see any code here that creates or references Bar it's impossible to say when it will be collected. For instance, if Bar is a singleton and stored somewhere in a static variable, it may live for a very long time - perhaps the entire lifetime of the program. You can't really know without seeing all of the code that manipulates and manages Bar.
I highly recommend reading the following article:
Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects
It explains how the .NET runtime works at a low level, and explains internal nuances like Loader Heaps and how static classes/members work. Technically speaking, there IS an initial instantiation of the 'static instnace' of a classes static members. However, this initiation is handled by the runtime in a different way than it is handled for class instances. Static classes are stored on loader heaps, which are not GC managed. Loader heaps are allocated and grown in a static manner, and are not compacted. The article is a great read, and should give you a thourough understanding of how the CLR operates.
(NOTE: I am not certain of how valid this article is for .NET 4. I do know that there were GC changes in .NET 4, however I am not sure how many fundamental runtime changes there are. The introduction of the DLR and other features may deviate from the explanation in the above article to some degree.)
Foo does not need to be instantiated, neither will it get instantied upon the SomeCheck static method call as per result, you would get the value returned by the method itself, and not an instance of the class.
Please have a look at these references for further details:
Static vs Non-Static Methods;
Static Classes and Static Class Members (C# Programming Guide).
I do hope this helps! =)
It depends on the implementation of SomeMethod. The method will have to be invoked from somewhere, presumably a "driver" class which would instantiate Bar and call SomeMethod. For example:
public class Driver
{
public static void Main()
{
Bar bar = new Bar();
bar.SomeMethod();
}
}
Given your current implementation of SomeMethod, yes, you'd have to instantiate it.
However, as long as SomeMethod only makes a call to another static method, we could make make it static too. In which case you wouldn't have to create an instance of Bar to invoke the method. i.e.
public class Driver
{
public static void Main()
{
Bar.SomeMethod();
}
}
public class Manipulate
{
public static int Main(string[] args) {
Bar bar = new Bar();
bar.BarFoo();
Console.ReadKey();
return 0;
}
}
public class Foo {
public static bool SomeCheck() {
return true;
}
}
public class Bar {
// what happens when we access Foo to call SomeCheck?
public void BarFoo() {
if (Foo.SomeCheck()) {
Console.WriteLine("Hello am true");
}
}
}
Yes you need to create an instance of Bar but not for Foo class since it is a static metod. Only difference is, the static methods are called at class level(compile time) rather than object level(run time), so you don't need to instantiate the Foo class.