ASP MVC - Comet/Reverse Ajax/PUSH - Is this code thread safe?

I'm trying to implement comet style features by polling the server for changes in data and holding the connection open untill there is something to response with.

Firstly i have a static variable on my controller which stores the time that the data was last updated:

public static volatile DateTime lastUpdateTime = 0;

So whenever the data i'm polling changes this variable will be changed.

I then have an Action, which takes the last time that the data was retrieved as a parameter:

public ActionResult Push(DateTime lastViewTime)
{
    while (lastUpdateTime <= lastViewTime)
    { 
        System.Thread开发者_如何转开发ing.Thread.Sleep(10000);
    }
    return Content("testing 1 2 3...");
}

So if lastUpdateTime is less than or equal to the lastViewTime, we know that there is no new data, and we simply hold the request there in a loop, keeping the connection open, untill there is new information, which we could then send back to the client, which would handle the response and then make a new request, so the connection is essentially always open.

This seems to work fine but i'm concerned about thread safety, is this OK? Does lastUpdateTime need to be marked as volatile? Is there a better way?

Thanks

edit: perhaps i should use a lock object when i update the time value

private static object lastUpdateTimeLock = new object();

..

lock (lastUpdateTimeLock)
{
    lastUpdateTime = DateTime.Now;
}

---

Regarding your original question, you do have to be careful with DateTimes, since they're actual objects in the .NET runtime. Only a few data types can be natively accessed (eg ints, bools) without locking (assuming you're not using Interlocked). If you want to avoid any issues with Datetimes, you can get the ticks as a long and use the Interlocked class to manage them.

That said, if you're looking for comet capabilities in a .NET application, you're unfortunately going to have to go a lot further than what you've got here. IIS/ASP.NET won't scale with the approach you've got in place right now; you'll hit limits before you even get to 100 users. Among other things, you will have to switch to using async handlers, and implement a custom bounded thread pool for the incoming requests.

If you really want a tested solution for ASP.NET/IIS, check out WebSync, it's a full comet server designed specifically for that purpose.

---

Honestly my concern would be with the number of connections kept open and the empty while loop. The connections you're probably fine on, but I'd definitely want to do some load testing to be sure.

The while (lastUpdateTime <= lastViewTime) {} seems like it should have a Thread.Sleep(100) or something in there. Otherwise I'd think it would consume a lot of cpu cycles needlessly.

The lock does not seem necessary to me around lastUpdateTime = DateTime.Now since the previous value does not matter. If it were lastUpdateTime = lastUpdateTime + 1 or something, then maybe it would be.