I am working on some code which is something like this:
class A
{
static SomeClass a = new Someclass("asfae");
}
Someclass contains the required constructor.
The code for this compiles fine without any warning. But I get a code hazard in system:
"The Someclass ctor has been called from static constructor and/or
static initialiser"
This code hazard part of system just to make it better by warning about possible flaws in the system or if system can get into bad state because of this.
I read somewhere on the web that static constructor/initialiser can get into deadlock in c# if they wait for a thread to finish. Does that have something to do with this?
I need to get rid of this warning how can i do this.
I can't make the member unstatic as it's used by a static function.
What should I do in this case , Need help.
You could hide it behind a property and initialize it on first use (not thread-safe);
class A
{
static SomeClass aField;
static SomeClass aProperty
{
get
{
if (aField == null) { aField = new Someclass("asfae"); }
return aField;
}
}
}
or use Lazy (thread-safe):
class A
{
static Lazy<SomeClass> a = new Lazy<SomeClass>(() => new Someclass("asfae"));
}
...or this very verbose thread safe version :)
class A
{
static SomeClass aField;
static object aFieldLock = new object();
static SomeClass aProperty
{
get
{
lock (aFieldLock)
{
if (aField == null) { aField = new Someclass("asfae"); }
return aField;
}
}
}
}
By initialising it as a static field, it behaves as it would in a static constructor, i.e. it probably gets initialised the first time an instance of your class is instantiated, but might happen earlier. If you want more control over exactly when the field is initialised, you could use Lazy<T>, e.g.:
{
static Lazy<SomeClass> a = new Lazy<SomeClass>(() => new Someclass("asfae"));
}
This way, you know that the initialisation of SomeClass will only happen the first time the field is accessed and its Value property called.
I think to understand your problem you need to know the difference between static constructors and type initializers, there is a great article from Jon Skeet about this issue:
http://csharpindepth.com/Articles/General/Beforefieldinit.aspx
The point is that following constructions are not the same, and there are difference in the behavior:
class Test
{
static object o = new object();
}
class Test
{
static object o;
static Test()
{
o = new object();
}
}
In any case, you could try to create a static constructor for your class to be able to have more control on this initialization, and maybe the warning will disappear.
If the member is only used by a static method, and only by this one, I would recommend you to put it in the scope if this static method and not as class member.
Related
First, a general note, what Xamarin calls their "linker" is actually more of a "dead code remover". It is supposed to prevent uncallable code from making it into the compiled app.
I have a type in my app. When I use reflection to get its constructors, I see zero constructors:
private static int GetConstructorCount(Type type) {
ConstructorInfo[] constructors = type.GetConstructors();
return constructors.Count();
}
Yet when I use reflection to see its instance members, I see many:
private static void LogMemberInfo(Type type) {
int constructorCount = GetConstructorCount(type);
MyLoggingMethod(constructorCount, "Constructors");
MemberInfo[] members = type.GetMembers();
List<string> willLog = new List<string>();
foreach(MemberInfo member in members) {
if (member.DeclaringType == type) {
willLog.Add(member.Name);
}
}
willLog.Sort();
foreach (string str in willLog) {
MyLoggingMethod.LogLine(str);
}
}
Output from the above is:
0 Constructors
lots of surviving members, including instance members
This is a problem, because the type is a gateway to a whole lot of other types. I was hoping that by getting rid of all the constructors, all the instance members would disappear. They don't.
Is this a bug in the linker? Or is there a reason why it might still not want to get rid of instance members?
I do access members of the type via casting. Perhaps this is the problem?
public class MySuperclass {
public static MySuperclass Instance {get; set;}
}
public MyClass: MySuperclass {
public static SomeMethod() {
MySuperclass object = MySuperclass.Instance;
MyClass castObject = object as MyClass; // castObject will always be null, as no constructors survived the linking process. But maybe the linker doesn't realize that?
if (castObject!=null) {
castObject.InstanceMethod();
}
}
}
UPDATE: Getting rid of all the casts did not solve the problem. I am calling virtual members of superclass objects in lots of places; that's my next guess, but if that's the problem, fixing will be messy.
At least in my case, calling any static method on a type leads to preservation of lots of instance members. I literally tried this:
public class MyType() {
public static bool DummyBool() {
return true;
}
// instance members here
}
Once the type was getting removed by the linker, I put in a call to MyType.DummyBool(). This led to a lot of instance members being preserved.
This may not be the case for everyone. But it was the case for me.
Another insidious thing to watch out for is that if a static class has any properties that are initialized on startup, and the class as a whole is preserved, then those properties are preserved, even if they are never called:
public static class StaticClass {
public static Foo FooProperty {get;} = new Foo(); // if any code that is not removed calls StaticClass.SomeString, then Foo will be preserved.
public static string SomeString {
get {
return "Hello";
}
}
}
I am also seeing at least one case where code in a class that is removed by the linker nonetheless causes another class not to be removed. I assume this is a bug; however, my example is rather involved, and my attempts to get a simple repro have failed.
Have you tried using the Preserve attribute? The linker will not "optimize" code decorated with it:
[Xamarin.iOS.Foundation.Preserve]
For more information see the Xamarin documentation here
I'm implementing a singleton pattern, and need the initialization to be thread safe.
I've seen several ways to do it, like using the double check lock implementation, or other techniques (i.e.: http://csharpindepth.com/articles/general/singleton.aspx)
I wanted to know if the following approach, which is similar to the fourth version in the article, is thread safe. I'm basically calling a method in the static field initializer, which creates the instance. I don't care about the lazyness. Thanks!
public static class SharedTracerMock
{
private static Mock<ITracer> tracerMock = CreateTracerMock();
private static Mock<ITracer> CreateTracerMock()
{
tracerMock = new Mock<ITracer>();
return tracerMock;
}
public static Mock<ITracer> TracerMock
{
get
{
return tracerMock;
}
}
}
Yes, that's thread-safe - although it's not the normal singleton pattern, as there are no instances of your class itself. It's more of a "single-value factory pattern". The class will be initialized exactly once (assuming nothing calls the type initializer with reflection) and while it's being initialized in one thread, any other thread requesting TracerMock will have to wait.
Your code can also be simplified by removing the method though:
public static class SharedTracerMock
{
private static readonly Mock<ITracer> tracerMock = new Mock<ITracer>();
public static Mock<ITracer> TracerMock { get { return tracerMock; } }
}
Note that I've made the field readonly as well, which helps in terms of clarity. I generally stick trivial getters all on one line like this too, to avoid the bulk of lots of lines with just braces on (7 lines of code for one return statement feels like overkill).
In C# 6, this can be simplified even more using a readonly automatically implemented property:
public static class SharedTracerMock
{
public static Mock<ITracer> TracerMock { get; } = new Mock<ITracer>();
}
Of course, just because this property is thread-safe doesn't mean that the object it returns a reference to will be thread-safe... without knowing about Mock<T>, we can't really tell that.
I have my singleton as below:
public class CurrentSingleton
{
private static CurrentSingleton uniqueInstance = null;
private static object syncRoot = new Object();
private CurrentSingleton() { }
public static CurrentSingleton getInstance()
{
if (uniqueInstance == null)
{
lock (syncRoot)
{
if (uniqueInstance == null)
uniqueInstance = new CurrentSingleton();
}
}
return uniqueInstance;
}
}
I would like check, if I will have two thread, are there two different singletons? I think, I shall have two different singletons (with different references), so what I'm doing:
class Program
{
static void Main(string[] args)
{
int currentCounter = 0;
for (int i = 0; i < 100; i++)
{
cs1 = null;
cs2 = null;
Thread ct1 = new Thread(cfun1);
Thread ct2 = new Thread(cfun2);
ct1.Start();
ct2.Start();
if (cs1 == cs2) currentCounter++;
}
Console.WriteLine(currentCounter);
Console.Read();
}
static CurrentSingleton cs1;
static CurrentSingleton cs2;
static void cfun1()
{
cs1 = CurrentSingleton.getInstance();
}
static void cfun2()
{
cs2 = CurrentSingleton.getInstance();
}
}
I suppose that I should got currentCounter = 0 (in this case every two singleton are different - because are creating by other threrad). Unfortunately, I got for example currentCounter = 70 so in 70 cases I have the same singletons... Could you tell me why?
I would like check, if I will have two thread, are there two different singletons
No, there are not. A static field is shared across each entire AppDomain, not each thread.
If you want to have separate values per thread, I'd recommend using ThreadLocal<T> to store the backing data, as this will provide a nice wrapper for per-thread data.
Also, in C#, it's typically better to implement a lazy singleton via Lazy<T> instead of via double checked locking. This would look like:
public sealed class CurrentSingleton // Seal your singletons if possible
{
private static Lazy<CurrentSingleton> uniqueInstance = new Lazy<CurrentSingleton>(() => new CurrentSingleton());
private CurrentSingleton() { }
public static CurrentSingleton Instance // use a property, since this is C#...
{
get { return uniqueInstance.Value; }
}
}
To make a class that provides one instance per thread, you could use:
public sealed class InstancePerThread
{
private static ThreadLocal<InstancePerThread> instances = new ThreadLocal<InstancePerThread>(() => new InstancePerThread());
private InstancePerThread() {}
public static InstancePerThread Instance
{
get { return instances.Value; }
}
}
By default, a static field is a single instance shared by all threads that access it.
You should take a look at the [ThreadStatic] attribute. Apply it to a static field to make it have a distinct instance for each thread that accesses it.
Use of a locking object ensures that only one value gets created; you can verify this by putting some logging in your CurrentSingleton constructor.
However, I think there's a small gap in your logic: imagine that two threads simultaneously call this method, while uniqueInstance is null. Both will evaluate the = null clause, and advance to the locking. One will win, lock on syncRoot, and initialize uniqueInstance. When the lock block ends, the other will get its own lock, and initialize uniqueInstance again.
You need to lock on syncRoot before even testing whether uniqueInstance is null.
No matter what you do you are never going to get currentCounter = 0.
Because we are forgetting the the fact that application/C# code is also running in some thread and there are some priorities set by C# to run the code. If you debug the code by putting break points in Main method and CurrentSingleton you will notice that. By the time you reach and create the new Object for CurrentSingleton, for loop may be iteration 3 or 4 or any number. Iterations are fast and code is comparing null values and Object or Object and null value. And I think this is the catch.
Reed has got point static will always be shared hence you need to change your code in following way
public class CurrentSingleton
{
[ThreadStatic]
private static CurrentSingleton uniqueInstance = null;
private static object syncRoot = new Object();
private CurrentSingleton() { }
public static CurrentSingleton getInstance()
{
if (uniqueInstance == null)
uniqueInstance = new CurrentSingleton();
return uniqueInstance;
}
}
And as per analysis you are getting two different objects at 70th iteration but, that is something just mismatch may be null and Object or Object and null. To get successful two different object you need to use [ThreadStatic]
Why C# allows initializing static class variables in non-static contructor? The static variables should only be allowed to be initialized on static constructors. Any ideas?
public class customer
{
public string Name;
public customer()
{
Name = "C1";
Console.WriteLine("creating customer " + Name);
}
}
class Program
{
public static customer cust;
public Program()
{
cust = new customer(); //Why is this allowed i.e. initialize a static variable in non-static constructor?
}
static void Main(string[] args)
{
Program program = new Program();
program = new Program();
Console.Read();
}
}
Don't look at it as initializing, look at it as setting.
If you would only like it to be initialized via a static constructor or at declaration, add the readonly keyword.
E.g.
public readonly static customer cust;
//Allowed
static Program()
{
cust = new customer();
}
//Not Allowed
public Program()
{
cust = new customer();
}
The short answer is there is no reason why not to allow this. Static variables can be reached anywhere from within the class (and outside, if they're public) and the constructor is no exception. This includes changing their value, or initializing them to a new value.
There are, in fact, several patterns that can take advantage of this behavior. For example, initializing a static object the first time a class is instantiated (perhaps for caching properties that are expensive to initialize but don't change in the future). Another use might be incrementing a counter to keep track of how many of these objects are alive.
With that said, you'd want to be aware of static objects in a class before initializing, and check to see if they're null before overwriting their values.
You can access and modify a static variable from any nonstatic function, it will just overwrite the value each time it is called. The opposite is not true, though - static functions can't access nonstatic variables.
It just means that the static variable is reset every time a new object is initialized. A bit weird, but the compiler allows it.
Is there anyway way to prevent a class having static instances of it created in C#. I don't think there is but it could be useful. E.g just some attribute to prevent it.
something like this
[NoStaticInstances]
public class MyClass {
}
so that
public static MyClass _myClass;
would cause an error?
There's no such thing as a "static instance" - there's only a static variable, which is assigned a value. And there's no way of preventing static variables of a particular type being declared, unless you make the type itself static, which will prevent any instances being created and any variables of that type from being declared.
Imagine if your desired feature did exist... how would you expect the following code to behave?
class Test
{
static object foo;
static void Main()
{
MyClass bar = new MyClass();
foo = bar;
}
}
Which line of that would cause an error, if any? If it's the assignment, imagine this instead:
class Test
{
static object foo;
static void Main()
{
MyClass bar = new MyClass();
object tmp = bar;
foo = tmp;
}
}
In short, I don't think you're going to be able to prevent static variables holding references to instances of your class. Out of interest, why do you want to?
What you can do is the following:
public class MyClass
{
public MyClass()
{
#if DEBUG // Only run in debug mode, because of performance.
StackTrace trace = new StackTrace();
var callingMethod = trace.GetFrames()[1].GetMethod();
if (callingMethod.IsStatic &&
callingMethod.Name == ".cctor")
{
throw new InvalidOperationException(
"You naughty boy!");
}
#endif
}
}
Static fields will 'normally' be created by static constructors. What the above code does is looking at the calling method to see if it is a static constructor and if that's the case, throw an exception.
Note however, that this check is quite fragile and smart users can easily work around this by refactoring the creation of this method to another method. In other words, I agree with every body else that there is no good way to do this.
Such a restriction would not make sense.
What if you write
static object something = new YourClass();
Not really, there is no language or compiler feature that supports this.
No, there's no way to dictate the scope or lifetime of object references in C#.