Static fields are being accessed using the class name like this:
public class Me()
{
public static int a=5;
}
I can access it with Me.a, so it is attached to the class.
But when I look at:
static ThreadLocal<int> _x = new ThreadLocal<int> (() => 3);
It guarantees that each thread sees different copy of _x.
Didn't we just see that static is per class and not per thread? How does ThreadLocal manage to give each thread a different copy of _x?
Didnt we just see that static is per class and not per thread ?
Yes. So imagine that a ThreadLocal<T> instance holds a static Dictionary<Thread, T> that looks up the Value for the current thread.
That is probably not how it actually works but it's a simple explanation of how it's possible. You could write it yourself.
So you still have only 1 static _x. But _x.Value can be bound to anything, like the courrent Thread.
The reference _x will indeed be one per class, as per its static specifier. However, only the reference will be shared among all threads, not the value inside its object. When you access _x.Value, ThreadLocal<T> invokes system-specific code that provides storage on the current thread, and reads or writes to that thread-specific storage.
My C# isn't that great, so here's a C++ answer to the same effect: Imagine a hypothetical class that contains a large array:
class Foo
{
int array[HUGE];
int & get() { return array[this_thread_id()]; }
}:
Now you can have one single, global (or class-static) object:
Foo tlstorage;
To access it from anywhere you say tlstorage.get() = 12;. However, the data is stored in the slot that "belongs" to your current thread. The entire storage is global, but only one slice is exposed to each thread.
Other languages like C and C++ have native support for this concept, and when you decorate a global or static variable as "thread-local", the compiler builds something that amounts to the same effect automatically. Perhaps in C# this is a library feature, though it probably also maps to something intrinsic.
Related
I'm using a library that isn't thread safe but doesn't use other non thread safe external ressources.
It's a bit of a pain to make it thread safe (main reason it's not thread safe is that it uses a lot of static fields that it reads/writes to on a per instance basis, works just fine with many instances processed sequentially buy obviously fails if using multiple instances in parallel)
I'm thinking of doing the following as a quick fix that feels hackish and i'm wondering if there is anything inherently wrong with this approach.
Create an app domain per thread, marshall the thread data to that domain, load the library in each domain and run as many app domains as i have threads, then unload when done.
I understand this implies a slowdown (many library loads and lots of marshalling back and force) but that aside am i missing something obvious that makes this impossible?
How much of the library do you need to interact with? If it's not too huge you could build a wrapper around it. You call the wrapper's methods and it handles locking and makes thread safe calls to the inner library.
You can declare an interface, and the implementation is your wrapper class. Now in addition to solving the thread safety issue you've removed an untestable direct dependency on static methods.
It might be a little bit of work (if it's feasible, depending on the library) but it would definitely be a lot cleaner than creating app domains just to keep separate "instances" of static members.
// Class with static memebers
public class FooManager
{
public static void ManageFoo(Foo foo)
{
// Does some non thread-safe stuff
}
}
public interface IFooManager
{
void ManageFoo(Foo foo);
}
public class FooManagerWrapper : IFooManager
{
private static readonly object FooManagerLock = new object();
public void ManageFoo(Foo foo)
{
lock (FooManagerLock)
{
FooManager.ManageFoo(foo);
}
}
}
This blog post contains another example. Even if thread safety isn't an issue I don't want my code to have a direct dependency on static classes and methods (even if I wrote them.)
Suppose I have singleton class that acts as a data cache. Multiple threads will read from the cache, and a single thread will periodically refresh it. It looks something like this:
public sealed class DataStore
{
public static DataStore Instance { get { return _instance; } }
public Dictionary<Foo, Bar> FooBar { get; private set; }
static DataStore() { }
private DataStore() { }
public void Refresh() {
FooBar = GetFooBarFromDB();
}
private static readonly DataStore _instance = new DataStore();
}
My question is essentially, is it safe to Refresh() while other threads may be accessing FooBar? Do I need to be using locks, or are my getting and setting operations atomic? Do I need to explicitly declare volatile fields to back up my properties?
P.S., If someone can think of a more descriptive title for this question, I would gladly welcome it.
Edit: Fixed my example to correct obviously non-atomic code.
Yes, in cases like that you need explicit synchronization, because another thread could get FooBar and start reading it before you have finished writing.
If you do this, however,
public void Refresh() {
var tmp = new Dictionary<Foo, Bar>();
// Fill out FooBar from DB
FooBar = tmp;
}
then you wouldn't need to add explicit synchronization, because the switch from one reference over to the other reference is atomic.
Of course there is an implicit assumption here that there is no writing outside the Refresh method.
EDIT: You also should switch from an auto-implemented property to a manually implemented property with a backing variable declared with volatile modifier.
Your example is not thread-safe. Dictionary is not a thread-safe class and any thread could be reading while Refresh is being executed. You can either put a lock around or use one of the thread-safe classes like ConcurrentDictionary.
Because you are exposing the dictionary publicly then you run into more issues with the code you have written around access to the methods on the dictionary itself. As #Icarus has pointed out you should use ConcurrentDictionary but I would argue that any form of locking around the instance will not help you.
You can easily get one thread adding to the collection while another is iterating over it.
EDIT
What I am saying.. never expose a static Dictionary or any other collection type. Always use the concurrent version
Well, we agree that your current code is not thread-safe.
So, you must use synchronization features, because FooBar is your critical section.
If you let it be public, you are expecting that people outside the DataStore class will act accordingly. However, this is a poor design decision.
So, I would suggest you to wrap everything into your current class, with something like this: What's the best way of implementing a thread-safe Dictionary?
Suppose I have a class like below:
public static class Foo
{
public static int Do(int original)
{
int result=original + 1;
return result;
}
}
public class Bar
{
public void Invoke()
{
int result=Foo.Do(1);
}
}
Anyone can tell me how it be invoked in CLR? All we know that CLR is a virtual machine base on stack. An instance which would invoke Foo.Do() method has its own Call Stack. It push a int arg to Stack , and then call Foo.Do() method. I'm woudering whether few instances in multithreads invoke Foo.Do() would disturb each others? Every instance has a copy of Foo.Do() or rather?
Each thread has its own call stack set up. So when you call a function in one thread, the stack is changed only for that thread. Other threads can call whatever other functions they want, without affecting each other (aside from shared state, but that's another issue. The important thing is that the stack isn't shared).
I'm woudering whether few instances in multithreads invoke Foo.Do() would disturb each others? Every instance has a copy of Foo.Do() or rather?
In this case, each instance would be fine. There is no data shared between the separate threads, since Invoke and Foo.Do do not rely on any other shared state.
The main issues with multiple threads occur when you're trying to share data between the individual threads. At that point, you need to take care to synchronize the access to the shared data.
Perphas you should look at ThreadLocal API so you can have a thread specific storage. In your case as Reed suggested, it should not matter as there is no shared state but if there is any, it will matter as static storage is shared between threads until unless it is ThreadLocal
How can I find out how many objects are created of a class in C#?
You'd have to put a static counter in that was incremented on construction:
public class Foo
{
private static long instanceCount;
public Foo()
{
// Increment in atomic and thread-safe manner
Interlocked.Increment(ref instanceCount);
}
}
A couple of notes:
This doesn't count the number of currently in memory instances - that would involve having a finalizer to decrement the counter; I wouldn't recommend that
This won't include instances created via some mechanisms like serialization which may bypass a constructor
Obviously this only works if you can modify the class; you can't find out the number of instances of System.String created, for example - at least not without hooking into the debugging/profiling API
Why do you want this information, out of interest?
Is this a class that you've designed?
If so, add a counter to the class that is incremented in the constructor and decremented in Dispose.
Potentially you could make this a performance counter so you can track it in Performance Monitor.
Do static members of an instance class only live as long as the instance itself, or would the static member live throughout the life of the application?
For instance, say I have a Hashtable as a static property. If I added items to it from one "Instance" would they be available from another "Instance"?
They live throughout the lifetime of the AppDomain. (For Windows applications, that's usually the lifetime of the process; it may not be though, depending on exactly what you're doing. AppDomains are recycled periodically in ASP.NET.)
Don't think of static variables as being shared between instances - think of them as belonging to the type rather than any particular instance. This makes it easier to understand how things work when you sometimes never create any instances.
For example:
class Test
{
static int x = 0;
static void Main()
{
x = 10;
Console.WriteLine(x);
}
}
There are no instances around to "share" Test.x - but that's okay, because it's associated with the type Test rather than with instances of Test.
You could argue this is a pretty subtle distinction, but it's one I've found to be useful.