CODEWITHSUNDEEP
asp.netmultithreadinglocking
Stephen
Stephen

Reputation: 3084

Using 'Lock' in web applications

A few months ago I was interviewing for a job inside the company I am currently in, I dont have a strong web development background, but one of the questions he posed to me was how could you improve this block of code.

I dont remember the code block perfectly but to sum it up it was a web hit counter, and he used lock on the hitcounter.

lock(HitCounter)
{
   // Bla...
}

However after some discussion he said, lock is good but never use it in web applications!

What is the basis behind his statement? Why shouldnt I use lock in web applications?

Upvotes: 10

Views: 8799

Answers (7)

Dani
Dani

Reputation: 33

Late :), but for future readers of this, an additional point:

If the application is run on a web farm, the ASP's running on multiple machines will not share the lock object

So this can only work if 1. No web farm has to be supported AND 2. ASP is configured (non-default) NOT to use parallel instances during recycle until old requests are served (as mentioned by Andras above)

Upvotes: 2

Mark Avenius
Mark Avenius

Reputation: 13947

First of all, you never want to lock an object that you actually use in any application. You want to create a lock object and lock that:

private readonly object _hitCounterLock = new object();
lock(_hitCounterLock)
{
    //blah
}

As for the web portion of the question, when you lock you block every thread that attempts to access the object (which for the web could be hundreds or thousands of users). They will all be waiting until each thread ahead of them unlocks.

Upvotes: 3

Tim Lloyd
Tim Lloyd

Reputation: 38494

There is no special reason why locks should not be used in web applications. However, they should be used carefully as they are a mechanism to serialize multi-threaded access which can cause blocking if lock blocks are contended. This is not just a concern for web applications though.

What is always worth remembering is that on modern hardware an uncontended lock takes 20 nanoseconds to flip. With this in mind, the usual practice of trying to make code inside of lock blocks as minimal as possible should be followed. If you have minimal code within a block, the overhead is quite small and potential for contention low.

To say that locks should never be used is a bit of a blanket statement really. It really depends on what your requirements are e.g. a thread-safe in-memory cache to be shared between requests will potentially result in less request blocking than on-demand fetching from a database.

Finally, BCL and ASP.Net Framework types certainly use locks internally, so you're indirectly using them anyway.

Upvotes: 7

Rei Miyasaka
Rei Miyasaka

Reputation: 7126

Couple reasons...

  1. If you're trying to lock a database read/write operation, there's a really high risk of a race condition happening anyway because the database isn't owned by the process doing the lock, so it could be read from/written to by another process -- perhaps even a hypothetical future version of IIS that runs multiple processes per application.

  2. Locks are typically used in client applications for non-UI threads, i.e. background/worker threads. Web applications don't have as much of a use for multithreaded processing unless you're trying to take advantage of multiple cores (in which case locks on request-associated objects would be acceptable), because each request can be assumed to run on its own thread, and the server can't respond until it's processed the entire output (or at least a sequential chunk) anyway.

Upvotes: 0

Ali Tarhini
Ali Tarhini

Reputation: 5358

lock is only intended to be used for multithreaded applications where multiple threads require access to the same shared variable, thus a lock is exclusively acquired by the requesting thread and all pending threads will block and wait until the lock is released.

in web applications, user requests are isolated so there is no need for locking by default

Upvotes: 0

VdesmedT
VdesmedT

Reputation: 9113

This code will create a bottleneck for your application since all incoming request will have to wait at this point before the previous went out of the lock.

Upvotes: 0

Andras Vass
Andras Vass

Reputation: 11638

The application domain might be recycled.

This might result in the old appdomain still finishing serving some requests and the new appdomain also serving new requests.

Static variables are not shared between them, so locking on a static global would not grant exclusivity in this case.

Upvotes: 6

Related Questions