We Keep Coding

Single class instance serving multiple requests

I have a singleton client class in my solution, which calls an external service/APIs. There are no locks inside this class (nothing protecting variables being accessed by multiple threads).
If this singleton instance gets request 1, and while handling that request, it gets another request (request2). What happens? Does it continue processing request1 to completion, then serve request 2? Or will it start serving request 2 at the same time which in turn might over-write any variables in this singleton class?
Thanks for the help!

When two threads concurrently execute a method on a single instance of a class, arguments passed to a method and variables defined within that method are not overwritten. The values of fields and properties, however, can be changed.
This class is thread safe:
public class Calculator
{
public long Add(int a, int b)
{
var result = a + b;
return result;
}
}
The arguments (a, b) and the variable (result) are stored in the stack frame, memory which is allocated each time the method is executed. So the result variable exists for each method call. Two method calls cannot share or overwrite that variable.
Similarly, if this method gets called while it's already executing, the a and b arguments are not overwritten.
As a result, any number of threads can safely call the Add method on a single instance of Calculator. They can do this concurrently. One execution does not wait for the other.
This class is not thread safe:
public class Calculator
{
private int _a;
private int _b;
public long Add(int a, int b)
{
_a = a;
_b = b;
var result = _a + _b;
return result;
}
}
It's a contrived example. The difference here is that calling Add modifies the state of the class, changing the _a and _b fields. It would be the same if these were properties instead of fields.
If two threads tried to execute this at once you would get unpredictable results. Right before the first thread adds _a and _b another thread might change the value of one of those fields.
This is the simple version. There are more complicated scenarios. Suppose, for instance, we pass a List<int> as an argument to a method. If another thread has a reference to the same list, both threads could try to modify it, or one could modify it while the other is reading it, all with unexpected results. How to manage all of that is outside the scope of this answer.
Here are a few takeaways:
Don't add state to class (fields and properties that change after its constructor is called) unless it's needed. There are scenarios where we must, and in some cases it's the whole purpose of the class. But if you can choose between the examples above, always choose the first one.
Whenever we pass around references to objects like lists or instances of our own classes, consider what would happen if two threads had access to that object. And then
Don't pass them around if they're not thread safe
Make them thread safe before they're passed around
Be very, very careful. This is the worst option because it puts a burden on us and future developers to simulate the behavior of the code in our heads and see potential problems. It's so much better to prevent problems than to figure out how to navigate around them.
Another way of describing it: Concurrency is like plutonium. It's powerful and useful, but we must always know where it is and make sure it never leaks.

Is it unsafe to use local variables in a call to begininvoke

I have to take over the source code of a bigger application from my colleaque that is written in C#. It uses windows forms an threads and right now it works as it should.
But one thing I am not sure about, is the way he handled parameters that are used in delegates that are raised from the thread to the windows forms in the application. I don't know why, but he defined many different object arrays with varying number of elements, eg:
private object[] delegateArray1;
private object[] delegateArray3;
private object[] delegateArray3A;
and in the code he used it then
delegateArray1 = new object[1]; // in the constructor of the thread class
delegateArray3 = new object[3];
delegateArray3a = new object[3];
// and this somewhere in the thread loop
delegateArray3[0] = systemtests.FehlerText;
delegateArray3A[1] = CheckState.Unchecked;
delegateArray3A[2] = testKanal;
sender.BeginInvoke(merkerInfoDelegate, delegateArray3);
whereby sender is the containercontrol from which the thread has been created.
merkerInfoDelegate points to a method with the signature
public void InfoAnzeige(string scrollText, CheckState state, int kanal);
The first question that I have:
Is it possible that my variables / objects that I pass to the BeginInvoke method are being garbage collected and thus are invalid when the delegate method gets finally executed. When yes, how do I prevent this from happen?
Is it not possible to call the delegate like this:
sender.BeginInvoke(merkerInfoDelegate, systemtests.FehlerText, CheckState.Unchecked, testKanal);
I would like to make the code more readable, more safe and more reliable. I think of declaring classes like the class MouseEventArgs, that consist of these parameters and that encapsulate all necessary data to be passed to the delegate method in the windows forms class...
public InfoDelegateEventArgs
{
public String Fehlertext;
public CheckState state;
public int Kanal;
}
this could be used like this:
idea = new InfoDelegateEventArgs(){...};
sender.BeginInvoke(merkerInfoDelegate, idea);

It is safe to pass "local" variables but remember they are no longer "local" once you pass them. The references have now been passed off to another operation that may be running concurrently on a separate thread. Now multiple threads have access to the "local" variable and thus it might require locking or other thread-safe treatment.
You don't need to worry about it being GC'd because there is still a reference that was passed to BeginInvoke.

Do I need to synchronize access the method arguments and locals when calling a method concurrently?

I have been writing a lot of code with static classes/methods that I believe will be called/executed simultaneously by multiple threads. So I am doing a lot of locking in my methods. I typically do this:
public static class MyThreadsafeMethods {
private static Object staticLock1 = new Object();
private static Object staticLock2 = new Object();
public static string StaticMethod1(string param1, int param2) {
lock (staticLock1) {
var _param1 = param1;
var _param2 = param2;
//highly confidential business logic here
return StaticMethod2(_param1, "Integer: " + _param2.ToString());
}
}
public static string StaticMethod2(string param1, string param2) {
lock (staticLock2) {
var _param1 = param1;
var _param2 = param2;
//truly groundbreaking algorithm here
return _param1 + " - " + _param2;
}
}
}
I am wondering two things:
1) I have thought that I need to be working with local "copies" of my parameters inside the "locked code"; because if another thread calls my method with different values for param1 and param2, that could mess up my processing. If I only work with variables that are declared/instantiated inside the locked code (i.e. _param1 and _param2 in the example above), then something could change the values of param1 and param2 (or send in references to different objects) and I am okay. But do I need to do that? Am I being unnecessarily paranoid?
2) I have decided that I don't want to instantiate my lock objects until I need them, because my collection of static locking objects is growing... So, I am now moving to doing this:
private static Object staticLock1;
public static string StaticMethod1(string param1, int param2) {
lock(staticLock1 = staticLock1 ?? new Object()) {
(...)
}
}
Is there any reason that instantiating my lock object the first time I need it is unsafe? Will using the assignment operator on my lock object in my lock statement somehow cause me problems or prevent the object from being properly locked?

What you have there won't make any difference at all - the arguments themselves cannot change after the call has been made, so it really does nothing. In your case with strings, it's perfectly safe seeing how string is immutable. When that isn't the case, it is possible that whatever is passed is altered somewhere else. In that case you'd have to make a real copy (i.e. not just copying the reference),
Consider the case where two threads arrive at lock(staticLock1 = staticLock1 ?? new Object()) at the same time. They could both see staticLock1 as null. So no that's not safe!

Your main confusion seems to be around what synchronization you need in order to safely call a static method concurrently.
Data races always arise because multiple threads access the same storage location in an unsynchronized way, and at least one of them is a writer. This basic rule is enough to reason about a lot of concurrency issues.
When you call a method, the arguments have different storage locations for each call. They are independent. Therefore, two threads calling the same method never race to access method arguments. You therefore never need to synchronize access to method arguments.
The same goes for locals. In fact, arguments have identical synchronization properties as locals have. They exist per call.
To answer your second issue: That is unsafe because two threads might lock on different objects. Also, you write to staticLock1 unsynchronized on multiple threads. I already explained that this is a data-race.

First: the overhead of creating an instance of Object is extremely small. Don't worry about it unless measurements show you that you should.
Just initialize like this:
private readonly static object staticLock1 = new Object();
The way you use the lock statement is not safe.
Secondly: I see no shared data in the methods so there is no reason to lock.
Finally: I would reconsider the design if it contains many static functions.

Static variable population best practice

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.

static methods and the call stack in IIS/asp.net

Theoretical question.
If you have 100 separate requests coming to an aspx web page that calls the static method below.
public static GeocodeResult GeocodeQuery(string query)
{
int train, tube, dlr = 0;
// manipulate these ints
if (train)
{
// do something important
}
}
Does every request have a separate call stack?
If so -
Does this static method call get pushed on these separate call stacks?
If so -
Therefore are these ints thread safe? ie. 100 requests, 100 call frames, 300 ints.
Cheers

Yes, each request has it's own call stack. And each stack will contain it's own values for query, train, tube, dir, since local variables and method parameters are stored in stack.
So, unless you are accessing some shared state, this method is thread safe.

All static methods are thread safe if the only variables it uses are local variables or parameters.

Note that it's not that a method has a call stack - a thread has a call stack. Methods are invoked by a thread.
Unless the method is inlined, invoking it may push parameters onto the call stack, but will definitely push the return address onto the call stack.
Each thread call stack is independent of the call stack of any other thread. If only the stack is accessed, then the method is thread-safe.
Other storage could be accessed to make the method not thread-safe. That includes static data and instance data as well as objects referenced by them. A static method has no access to instance data, which makes it easier for it to be thread-safe. You only need to watch out for access to static data, or objects referenced by static data:
private static int _balance;
private static void ThreadSafetyIssues()
{
// Not thread safe
int temp = _balance;
temp ++;
_balance = temp;
// Not thread safe
temp = (int) HttpContext.Current.Session["balance"];
temp ++;
HttpContext.Current.Session["balance"] = temp;
}
The HttpContext.Current property is static. This means that any thread can access the context at the same time, including Session. This is just as non-thread-safe as the simple static _balance field above.