Question

I wish to stop a thread from entering code while another thread is still executing that bit of code:

I’m currently going the following:
global.asax.cs

    private static bool _isProcessingNewIllustrationRequest;

    public static bool IsProcessingNewIllustrationRequest
    {
        get { return _isProcessingNewIllustrationRequest; }
        set { _isProcessingNewIllustrationRequest = value; }
    }

Then in MVC:

    public ActionResult CreateNewApplication()
    {
        if (!Global.IsProcessingNewIllustrationRequest)
        {
            Global.IsProcessingNewIllustrationRequest = true;

            // DO WORK... RUN CODE
            Global.IsProcessingNewIllustrationRequest = false;
            return View("Index", model);
        }
        else
        {
            // DISPLAY A MESSAGE THAT ANOTHER REQUEST IS IN PROCESS
        }
    }

But if seems as if the code isn’t working, because both threads(Chrome & Firefox) still executes the code at the same time.

UPDATED

private Object thisLock = new Object();     
public ActionResult CreateApplication()
        {
            ILog log = LogManager.GetLogger(typeof(Global));
            string aa = this.ControllerContext.HttpContext.Session.SessionID;
            log.Info("MY THREAD: " + aa);

            lock (thisLock)
            {
                Thread.Sleep(8000);

                DO SOME STUFF

            }
        }

Even with the log, thread 2 (Firefox session) still goes into the code while session1 (Chrome) is executing it with the lock. What am I missing?

Answer 1

I can see two obvious reasons why this code won’t do what you want.

Problem #1: It’s not threadsafe. Every time someone connects to your server, that request is going to run in a thread, and if multiple requests come in, then multiple threads are all going to be running at the same time. Several threads could very well read the flag at the same time, all see that it’s false, and so all enter their if block and all do their work, which is exactly what you’re trying to prevent.

This is a “race condition” (the results depend on who wins the race). Boolean variables aren’t enough to solve a race condition.

There are a bunch of ways to actually fix this problem. The best would be to remove the shared state, so each thread can run completely independently of the others and there’s no need to lock the others out; but I’ll assume you’ve already considered that and it’s not practical. The next things to look at are mutexes and monitors. Monitors are a little simpler to use, but they only work if both threads are actually in the same appdomain and the same process. That brings me to…

Problem #2: The two threads might not be in the same process. Recent versions of IIS will launch multiple separate worker processes to handle Web requests. Each process has its own address space, meaning each process (technically each appdomain within each process) has its own copy of your “global” variable!

In fact, if you’re building a really high-traffic Web site, the different worker processes may not even run on the same computer.

Worker processes are your most likely culprit. If you were facing a race condition, the problem would be incredibly rare (and even more incredibly hard to debug when it did come up). If you’re seeing it every time, my money is on multiple worker processes.

Let’s assume that all the worker processes will be on the same server (after all, if you had the kind of budget that required apps that can scale out to multiple Web servers, you would already know way more about multithreaded programming than I do). If everything’s on the same server, you can use a named Mutex to coordinate across different appdomains and processes. Something like this:

public static Mutex _myMutex = new Mutex(false, @"Global\SomeUniqueName");

public ActionResult CreateNewApplication()
{
    if (_myMutex.WaitOne(TimeSpan.Zero))
    {
        // DO WORK... RUN CODE
        _myMutex.ReleaseMutex();
        return View("Index", model);
    }
    else
    {
        // DISPLAY A MESSAGE THAT ANOTHER REQUEST IS IN PROCESS
    }
}

The WaitOne(TimeSpan.Zero) will return immediately if another thread owns the mutex. You could choose to pass a nonzero timespan if you expect that the other thread will usually finish quickly; then it will wait that long before giving up, which would give the user a better experience than failing instantly into a “please try again later” error message.