We Keep Coding

Will multiple Thread instances will refer to same memory block of static class or will it create separate memory block for every thread?

I am a newbie in .NET and have many confusions regarding the same. If for every request in a dotnet MVC web application a thread is created and inside that thread if we access static variables, then, will the static variables inside all the threads have common memory or will every single thread contain separate static memory variables?
I don't have any code currently.

Following is a bit of a simplification, but should provide enough context to answer your question.
The memory model for .NET is such that memory is generally shared across threads and can be done so without synchronizing access. Thus, if you have some class A, both its instance and static members can be accessed across threads. That is, of course, problematic because multiple threads accessing either could result in concurrency issues or corrupt state.
That said, it is possible to prevent this corruption in a few ways
use lock or some other form of mutual exclusion on both static and instance members
use statics with ThreadLocal or [ThreadStatic]
and, if state must be shared across threads, copy it so threads are accessing memory that (hopefully) the original thread won't touch
There are pros and cons to these. It is generally better to have no cross-thread dependencies. In the context of ASP.NET this is especially true. Ideally you want your APIs and/or web page renders to be completely independent with other calls and across calls.
If you find yourself needing static members (without ThreadLocal<T> or [ThreadStatic]) stick to making only read accesses (no writes) against these fields. But even then, the lifecycle of the static field matters; for example, if the static is initialized after requests start accessing the fields, you'll have trouble.

C# Threading - Using a class in a thread-safe way vs. implementing it as thread-safe

Suppose I want to use a non thread-safe class from the .Net Framework (the documentation states that it is not thread-safe). Sometimes I change the value of Property X from one thread, and sometimes from another thread, but I never access it from two threads at the same time. And sometimes I call Method Y from one thread, and sometimes from another thread, but never at the same time.
Is this means that I use the class in a thread-safe way, and the fact that the documentation state that it's not thread-safe
is no longer relevant to my situation?
If the answer is No: Can I do everything related to a specific object in the same thread - i.e, creating it and calling its members always in the same thread (but not the GUI thread)? If so, how do I do that? (If relevant, it's a WPF app).

No, it is not thread safe. As a general rule, you should never write multi threaded code without some kind of synchronization. In your first example, even if you somehow manage to ensure that modifying/reading is never done at the same time, still there is a problem of caching values and instructions reordering.
Just for example, CPU caches values into a register, you update it on one thread, read it from another. If the second one has it cached, it doesn't go to RAM to fetch it and doesn't see the updated value.
Take a look at this great post for more info and problems with writing lock free multi threaded code link. It has a great explanation how CPU, compiler and CLI byte code compiler can reorder instructions.

Suppose I want to use a non thread-safe class from the .Net Framework (the documentation states that it is not thread-safe).
"Thread-safe" has a number of different meanings. Most objects fall into one of three categories:
Thread-affine. These objects can only be accessed from a single thread, never from another thread. Most UI components fall into this category.
Thread-safe. These objects can be accessed from any thread at any time. Most synchronization objects (including concurrent collections) fall into this category.
One-at-a-time. These objects can be accessed from one thread at a time. This is the "default" category, with most .NET types falling into this category.
Sometimes I change the value of Property X from one thread, and sometimes from another thread, but I never access it from two threads at the same time. And sometimes I call Method Y from one thread, and sometimes from another thread, but never at the same time.
As another answerer noted, you have to take into consideration instruction reordering and cached reads. In other words, it's not sufficient to just do these at different times; you'll need to implement proper barriers to ensure it is guaranteed to work correctly.
The easiest way to do this is to protect all access of the object with a lock statement. If all reads, writes, and method calls are all within the same lock, then this would work (assuming the object does have a one-at-a-time kind of threading model and not thread-affine).

Suppose I want to use a non thread-safe class from the .Net Framework (the documentation states that it is not thread-safe). Sometimes I change the value of Property X from one thread, and sometimes from another thread, but I never access it from two threads at the same time. And sometimes I call Method Y from one thread, and sometimes from another thread, but never at the same time.
All Classes are by default non thread safe, except few Collections like Concurrent Collections designed specifically for the thread safety. So for any other class that you may choose and if you access it via multiple threads or in a Non atomic manner, whether read / write then it's imperative to introduce thread safety while changing the state of an object. This only applies to the objects whose state can be modified in a multi-threaded environment but Methods as such are just functional implementation, they are themselves not a state, which can be modified, they just introduce thread safety for maintaining the object state.
Is this means that I use the class in a thread-safe way, and the fact that the documentation state that it's not thread-safe is no longer relevant to my situation? If the answer is No: Can I do everything related to a class in the same thread (but not the GUI thread)? If so, how do I do that? (If relevant, it's a WPF app).
For a Ui application, consider introducing Async-Await for IO based operations, like file read, database read and use TPL for compute bound operations. Benefit of Async-Await is that:
It doesn't block the Ui thread at all, and keeps Ui completely responsive, in fact post await Ui controls can be directly updated with no Cross thread concern, since only one thread is involved
The TPL concurrency too makes compute operations blocking, they summon the threads from the thread Pool and can't be used for the Ui update due to Cross thread concern
And last: there are classes in which one method starts an operation, and another one ends it. For example, using the SpeechRecognitionEngine class you can start a speech recognition session with RecognizeAsync (this method was before the TPL library so it does not return a Task), and then cancel the recognition session with RecognizeAsyncCancel. What if I call RecognizeAsync from one thread and RecognizeAsyncCancel from another one? (It works, but is it "safe"? Will it fail on some conditions which I'm not aware of?)
As you have mentioned the Async method, this might be an older implementation, based on APM, which needs AsyncCallBack to coordinate, something on the lines of BeginXX, EndXX, if that's the case, then nothing much would be required to co-ordinate, as they use AsyncCallBack to execute a callback delegate. In fact as mentioned earlier, there's no extra thread involved here, whether its old version or new Async-Await. Regarding task cancellation, CancellationTokenSource can be used for the Async-Await, a separate cancellation task is not required. Between multiple threads coordination can be done via Auto / Manual ResetEvent.
If the calls mentioned above are synchronous, then use the Task wrapper to return the Task can call them via Async method as follows:
await Task.Run(() => RecognizeAsync())
Though its a sort of Anti-Pattern, but can be useful in making whole call chain Async
Edits (to answer OP questions)
Thanks for your detailed answer, but I didn't understand some of it. At the first point you are saying that "it's imperative to introduce thread safety", but how?
Thread safety is introduced using synchronization constructs like lock, mutex, semaphore, monitor, Interlocked, all of them serve the purpose of saving an object from getting corrupt / race condition. I don't see any steps.
Does the steps I have taken, as described in my post, are enough?
I don't see any thread safety steps in your post, please highlight which steps you are talking about
At the second point I'm asking how to use an object in the same thread all the time (whenever I use it). Async-Await has nothing to do with this, AFAIK.
Async-Await is the only mechanism in concurrency, which since doesn't involved any extra thread beside calling thread, can ensure everything always runs on same thread, since it use the IO completion ports (hardware based concurrency), otherwise if you use Task Parallel library, then there's no way for you to ensure that same / given thread is always use, as that's a very high level abstraction
Check one of my recent detailed answer on threading here, it may help in providing some more detailed aspects

It is not thread-safe, as the technical risk exists, but your policy is designed to cope with the problem and work around the risk. So, if things stand as you described, then you are not having a thread-safe environment, however, you are safe. For now.

Locking mechanism is needed for static functions?

I have created a CommonUtils.cs file containing 5 static functions (So that I can just "copy" this .cs for other projects in Visual Studio since I develop different C# applications) along with that I have many source files.
Now, I have compiled my project to a DLL. This dll is hosted via IIS server as an application. Many customers use this dll to perform something, say they generate a report.
I have been informed that "static functions" must not be used generously in this context and they should be applied, a "locking" mechanism since without lock, multiple threads of a single instance of program or multiple instances of a program, both can behave unexpectedly. Is it true?

I have been informed that "static functions" must not be used
generously in this context and they should be applied, a "locking"
mechanism since without lock, multiple threads of a single instance of
program or multiple instances of a program, both can behave
unexpectedly. Is it true?
Let's break it piece by piece. What is a static class?
A static class is basically the same as a non-static class, but
there is one difference: a static class cannot be instantiated. In
other words, you cannot use the new keyword to create a variable of
the class type. Because there is no instance variable, you access
the members of a static class by using the class name itself.
How CLR treats a static class?
As is the case with all class types, the type information for a static
class is loaded by the .NET Framework common language runtime (CLR)
when the program that references the class is loaded. The program
cannot specify exactly when the class is loaded. However, it is
guaranteed to be loaded and to have its fields initialized and its
static constructor called before the class is referenced for the first
time in your program. A static constructor is only called one time,
and a static class remains in memory for the lifetime of the
application domain in which your program resides.
Now why we may need locking?
Basically, locking is needed when we have race conditions. When someone may read data that someone else may alter them in the same time. Two separate threads have access to a shared resource and there isn't any mechanism to prevent this. In order you take an answer to your question, you have at first to answer another question.
Does your static methods access shared resources and there might be any race condition? If that's true, then you need to use locking. Otherwise, it is not needed.
For further information about static classes, please have a look here.
While if you need more information about thread synchronization techniques, please have a look here.

Functions are immutable so you don't need to synchronize when calling a function. Function parameters are mutable but each invocation has it's own local copy. No need to synchronize either.
Synchronization is required when multiple thread work on the same data and there is at least one writer. This is about any variable that is shared between threads. Care is required for static variables and any instance variable reachable by a static variables.

It sounds like you have a class library. Here are Microsoft's guidelines for class libraries that need to support multi threading:
Avoid the need for synchronization, if possible. This is especially true for heavily used code. For example, an algorithm might be adjusted to tolerate a race condition rather than eliminate it. Unnecessary synchronization decreases performance and creates the possibility of deadlocks and race conditions.
Make static data (Shared in Visual Basic) thread safe by default.
Do not make instance data thread safe by default. Adding locks to create thread-safe code decreases performance, increases lock contention, and creates the possibility for deadlocks to occur. In common application models, only one thread at a time executes user code, which minimizes the need for thread safety. For this reason, the .NET Framework class libraries are not thread safe by default.
Avoid providing static methods that alter static state. In common server scenarios, static state is shared across requests, which means multiple threads can execute that code at the same time. This opens up the possibility of threading bugs. Consider using a design pattern that encapsulates data into instances that are not shared across requests. Furthermore, if static data are synchronized, calls between static methods that alter state can result in deadlocks or redundant synchronization, adversely affecting performance.
Copied from https://msdn.microsoft.com/en-us/library/1c9txz50(v=vs.110).aspx

Explanation for "LOCK" From MSDN says:
The lock keyword marks a statement block as a critical section by obtaining the mutual-exclusion lock for a given object, executing a statement, and then releasing the lock.
The lock keyword ensures that one thread does not enter a critical section of code while another thread is in the critical section. If another thread tries to enter a locked code, it will wait, block, until the object is released
References:
https://msdn.microsoft.com/en-us/library/c5kehkcz.aspx
Its better to use LOCK in Multithreading than creating Static functions everytime.

Can a method from a singleton object be called from multiple threads at the same time?

I have a component registered in Castle Windsor as a singleton. This object is being used in many other places within my application which is multithreaded.
Is it possible that the two objects will invoke the same method from that singleton at the same time or 'calling it' will be blocked until the previous object will get result?
Thanks

You can call a Singleton object method from different threads at the same time and they would not be blocked if there is no locking/ synchronization code. The threads would not wait for others to process the result and would execute the method as they would execute methods on separate objects.
This is due to the fact that each thread has a separate stack and have different sets of local variables. The rest of the method just describes the process as to what needs to be done with the data which is held the variables/fields.
What you might want to take care of is if the methods on the Singleton object access any static methods or fields/variables. In that case you might need to work on synchronization part of it. You would need to ensure multi-threaded access to shared resources for the execution of the method to be reliable.
To be able to synchronize, you might need to use lock statement or other forms of thread synchronization techniques.
You might want to refer to this article from Wikipedia which provides information on C# thread local storage as well.

You can call the same method or different methods on one object simultaneously from different threads. In the specific methods you'll need to know when sensitive variables are being accessed (mostly when member-variables are changing their values) and will need to implement locking on your own, in order to solve lost updates and other anomalies.
You can lock a part of a code with the lock-statement and here an article on how Thread-Synchronization works in .Net.

The normal version of Singleton may not be thread safe, you could see different implementation of thread safe singleton here.
http://tutorials.csharp-online.net/Singleton_design_pattern:_Thread-safe_Singleton

msdn: What is "Thread Safety"?

In many MSDN documents, this is written under the Thread Safety heading;
"Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe."
for example; here
can someone explain it please in a rather simple way?
Thank you :)

Eric Lippert has an excellent blog post about this. Basically it's somewhat meaningless on its own.
Personally I don't trust MSDN too much on this front, when I see that boiler-plate. It doesn't always mean what it says. For example, it says the same thing about Encoding - despite the fact that we all use encodings from multiple threads all over the place.
Unless I have any reason to believe otherwise (which I do with Encoding) I assume that I can call any static member from any thread with no corruption of global state. If I want to use instance members of the same object from different threads, I assume that's okay if I ensure - via locking - that only one thread will use the object at a time. (That's not always the case, of course. Some objects have thread affinity and actively dislike being used from multiple threads, even with locking in place. UI controls are the obvious example.)
Of course, it becomes tricky if objects are being shared unobviously - if I have two objects which each share a reference to a third, then I may end up using the first two objects independently from different threads, with all the proper locking - but still end up corrupting the third object.
If a type does advertise itself to be thread safe, I'd hope that it would give some details about it. It's easy if it's immutable - you can just use instances however you like without worrying about them. It's partially or wholly "thread-safe" types which are mutable where the details matter greatly.

You may access any public static member of that class from multiple threads at the same time, and not disrupt the state of the class. If multiple threads attempt to access the object using instance methods (those methods not marked "static") at the same time, the object may become corrupted.
A class is "thread-safe" if attempts to access the same instance of the class from multiple threads at the same time does not cause problems.

An object being "thread safe" means that if two threads are using it at (or very near, on single-CPU systems) the exact same time, there's no chance of it being corrupted by said access. That's usually achieved by acquiring and releasing locks, which can cause bottlenecks, so "thread safe" can also mean "slow" if it's done when it doesn't need to be.
Public static members are pretty much expected to be shared between threads (Note, VB even calls it "Shared"), so public statics are generally made in such a way that they can be used safely.
Instance members aren't usually thread-safe, because in the general case it'd slow things down. If you have an object you want to share between threads, therefore, you'll need to do your own synchronization/locking.

To understand this, consider the following example.
In MSDN description of .net class HashSet, there is a part that says about the thread safety. In the case of HashSet Class, MSDN says “Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.”
Of cause we all know the concept of race conditions and deadlocks, but what does Microsoft wants to say in simple English?
If two threads add two values to an “instance” of a HashSet there are some situation where we can get its count as one. Of cause in this situation the HashSet object is corrupted since we now have two objects in the HashSet, yet its count shows only one. However, public static version of the HashSet will never face such a corruption even if two threads concurrently add values.