static class and multiple simultaneous requests

Suppose I have a static helper class that I'm using a lot in a web app. Suppose that the app receives about 20 requests per second for a sustained period of time and that, by magic, two requests ask the static class to do some work at the exact same nanosecond.

What happens when this happens?

To provide some context, the class is a used to perfor开发者_如何学Cm a linq-to-sql query: it receives a few parameters, including the UserID, and returns a list of custom objects.

thanks.

It entirely depends on what your "some work" means. If it doesn't involve any shared state, it's absolutely fine. If it requires access to shared state, you'll need work out how to handle that in a thread-safe way.

A general rule of thumb is that a class's public API should be thread-safe for static methods, but doesn't have to be thread-safe for instance methods - typically any one instance is only used within a single thread. Of course it depends on what your class is doing, and what you mean by thread-safe.

What happens when this happens?

If your methods are reentrant then they are thread safe and what will happen is that chances are they will work. If those static methods rely on some shared state and you haven't synchronized access to this state chances are this shared state will get corrupted. But you don't need to hit the method at the same nanosecond by 20 requests to corrupt your shared state. 2 suffice largely if you don't synchronize it.

So static methods by themselves are not evil (well actually they are as they are not unit test friendly but that's another topic), it's the way they are implemented that matters in a multithreaded environment. So you should make them thread safe.

UPDATE:

Because in the comments section you mentioned LINQ-TO-SQL as long as all variables used in the static method are local, this method is thread-safe. For example:

public static SomeEntity GetEntity(int id)
{
    using (var db = new SomeDbContext())
    {
        return db.SomeEntities.FirstOrDefault(x => x.Id == id);
    }
}

you must ensure your methods are thread safe, so don't use static attributes to store any kind of state. If you are declaring new objects inside the static method, there is no problem because each thread have its own object.

It depends if the static class has any state or not (i.e. static variables shared across all calls). If it does not, then it's fine. If it does, it's not good. Examples:

// Fine
static class Whatever
{
    public string DoSomething() {
        return "something";
    }
}

// Death from above
static class WhateverUnsafe
{
    static int count = 0;
    public int Count() {
        return ++count;
    }
}

You can make the second work fine using locks, but then you introduce deadlocks and concurrency issues.

I have built massive web applications with static classes but they never have any shared state.

It crashes out in a nasty way (if you are doing this to share state), avoid doing this in a webapp... Or alternativly protect the reads/writes with a lock:

http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlockslim.aspx

But honestly you really should avoid using statics, unless you REALLY have to, and if you really have to you have to be very careful with your locking strategy and test it to destruction to make sure have managed to isolated reads and writes from each other