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 my C# static method in a non static class thread safe?

I have a C# class that can be instantiated with different constructors, but it also contains some static helper methods which only work with their parameters and can be called from other classes as well.
Now I wonder whether concurrent calls from different threads to such a method is thread safe or not, or in other words, is it possible that variables inside the static method get changed by call2, while call1 is still in process?
public class AwesomeClass
{
/* constructors and stuff */
public static bool HelperMethod(object o1)
{
string someString = "";
Func<object, string> doSomething = (o) => {
string someOtherString == null;
if (someString.Length == 0)
{
/* time consuming process using o... frequently
changes someString and someOtherString */
}
return someOtherString;
};
return doSomething(o1).Length > 0 && someString.Length < 10;
}
}
If someString in the example could be changed by a thread2 calling HelperMethod while doSomething is still working for thread1, I'd be in trouble.

If your static method does not change any member variables, and does not call mutating methods on its parameters, it is re-entrant, and is, therefore, thread-safe.
Static methods that perform mutating operations on their parameters may not be thread-safe when concurrent threads invoke the method with the same object as its parameter.
For example, if your method mutates o1 through methods, properties, or public variables, the method would no longer be thread-safe.

HelperMethod is thread safe because it does not access any shared data. someString is local variable and it will be allocated again every time the method is called.
Note that this answer is not affected by the fact that someString is part of the closure. Separate closure object (which contains particular instance of someString) will be allocated on stack with every call to the HelperMethod.

The variables someString and someOtherString are local to the call, they are not shared between calls. This is just as if had a function call itself, modifying variables in the 2nd call would not modify the first.
The one thing that could be unsafe is time consuming process using o..., If the operations you are doing to o1 are not safe to be done by multiple threads at once you could run into issues.

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 members and instance methods for multiple requests at the same time

If I define an object like a logger object as static in a class, then call a method like the following:
public class Manager
{
private static ClientLogManager log = new ClientLogManager();
public void Log(string Message)
{
log.Debug(string Message);
}
}
This is defined in a class library project.
My understanding is that the static variable is shared between all requests for this application, so the log object is shared. However the method Debug itself is not static, but the object is static, so there will be only one instance of this method. Is that correct?
If a lot of users are calling this code at the same time, if 2 requests are calling the log.Debug method at the same time, can the message of the 2nd request overwrite the message of the 1st request?
Also, is it better to replace this with a Singleton? wouldn't it be one Singleton object per request?
Here is the ClientLogManager code
public class ClientLogManager
{
#region Member Variables
private static readonly ILog _log = LogManager.GetLogger(typeof(ClientLogManager));
#endregion
#region Constructors
public ClientLogManager()
{
}
#endregion
#region Public Methods
public void Debug(string message)
{
_log.Debug(message);
}
#endregion
}

If a lot of users are calling this code at the same time, if 2 requests are calling the log.Debug method at the same time, can the message of the 2nd request overwrite the message of the 1st request?
Yes, unless the logger is specifically written to support this. Most loggers are designed to support this, so unless you rolled your own from scratch chances are it will synchronize all writes internally (so that you don't have to). If you are unsure you should check the documentation for the specific logger you are using to see if it will support or break when written to simultaneously.

"My understanding is that the static variable is shared between all requests for this application, so the log object is shared."
Correct, there exists only 1 instance of a static member per AppDomain.
"However the method Debug itself is not static, but the object is static, so there will be only one instance of this method. Is that correct?"
The statement in itself is correct, but...
What it boils down to is this:
Both static and instance methods "exist" only once in memory, the difference is that
a static method does not need an instance of the class it's declared on in order to
be executed, whereas an instance method does.
If multiple requests can be handled concurrently, they have to be executed on different
threads. Each thread has its own call stack, and if you use a thread to perform a method
call on, the arguments passed to that method are placed on the call stack of that thread.
This means that, as long as the argument is either a valuetype (such as an int) or an
immutable type (such as in this case, a string) it cannot be modified by another thread
(because it is either not visible from another thread, or not modifyable).
Hence, you don't have to worry that the messages get mixed up inside your Manager.Log() or ClientLogManager.Debug() method.
So, both your current Manager and ClientLogManager implementations are thread-safe (at least, if the _log instance is thread-safe).
Once you start declaring non-static member variables in your Manager class, and
you're going to use them in Manager.Log(), then it is no longer thread-safe:
The same Manager instance could then be accessed by multiple threads, and once they
all start writing in the same member variable, you're in trouble...
I hope this clarifies things a bit.

Execute static method in multithreads

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