Another bad lock pattern

re: Another bad lock pattern

Dejan Jelovic — Sun, 07 Dec 2003 15:25:00 GMT

Are you regretting your decission to enable any object to be used as a mutex yet? ;>

re: Another bad lock pattern

Rico Mariani — Sun, 07 Dec 2003 20:33:00 GMT

no comment :)

re: Another bad lock pattern

Ian Ringrose — Mon, 08 Dec 2003 11:33:00 GMT

When I implement a singleton in C#, I often use typeof(class), is this a real problem. I do not see how it can give a dead lock. After all one else should be using my class in a lock statement. I agree with using a separate lock object if the locking is any more complex then this.

class A
(
private A()
{
// some complex code...
}

public static A Get()
{
if (msOneAnyOnly == null)
{
lock(typeof(A))
{
if (msOneAnyOnly == null)
{
msOneAnyOnly = new A();
}
}
}

return msOneAnyOnly;
}

private A msOneAnyOnly;
)

re: Another bad lock pattern

Rico Mariani — Mon, 08 Dec 2003 12:51:00 GMT

There are three problems with lock(typeof(A)):

First: type objects are agile, so the same type object is used in all appdomains. That means if your code is running in two different appdomains they will share the same lock which is probably a bad idea.

Second: type objects are public, so anyone anywhere can do lock(typeof(A)) which could totally mess your algorithm up.

Third: typeof() isn't free, you'll have to drag in a bunch of reflection code.

So, avoiding lock(typeof(X)) results in faster, simpler, and more correct code. In contrast I can't think of any benefits to using lock(typeof(X)) under any circumstances.

re: Another bad lock pattern

Rico Mariani — Mon, 08 Dec 2003 12:58:00 GMT

Clarification: In your particular example the first problem doesn't matter much. Really the third is the big issue. It's much cheaper to have a static variable that holds the lock explicitly.

re: Another bad lock pattern

Wesner Moise — Sat, 31 Jan 2004 20:47:00 GMT

In an NGEN app, doesn't using a static initializer introduce new additional checks before every function call?

Thus, in fixing the lock, we slowed the class down.

re: Another bad lock pattern

Rico Mariani — Sat, 31 Jan 2004 21:15:00 GMT

I think typically not. If you put the test in the constructor for instance, then you mostly don't have to worry about instance methods being called having not initialized the statics because if you have an instance then you necessarily have run the constructor.

There are complicated rules for this but it ends up not costing too much. Also this is only an issue for domain nuetral code.

In any case, the cost of typeof() is greater than just a single test... even if there was an extra test in every method that used the lock, it would still be faster.

re: Another bad lock pattern

Rico Mariani — Sat, 31 Jan 2004 21:21:00 GMT

Actually, I think going into the exact details of this process would make an interesting blog/article. First I'll see if someone has already done a good job on this topic.

Integrated mode roadblock: Request is not available in this context exception in Application_Start

Mike Volodarsky's ServerSide — Sun, 11 Nov 2007 05:43:20 GMT

The “Request is not available in this context” exception is one of the most common errors

System.Web.HttpException: Request is not available in this context - Asp.Net Classifieds Starter Kit Does Not Run in IIS7

Blog By Regan — Sat, 26 Jul 2008 02:34:19 GMT

As we have found in deploying 2 projects to the new release of IIS in the past month that there were

IIS7 Integrated mode: Request is not available in this context exception in Application_Start

Blog By Regan — Sat, 26 Jul 2008 04:34:20 GMT

As we have found in deploying 2 projects to the new release of IIS in the past month that there were

IIS7 Integrated mode: Request is not available in this context exception in Application_Start

Regan Schroder — Mon, 28 Jul 2008 08:56:29 GMT

The “Request is not available in this context” exception is one of the more common errors you may receive

lock file in ASP.NET | keyongtech

lock file in ASP.NET | keyongtech — Thu, 22 Jan 2009 09:49:35 GMT

PingBack from http://www.keyongtech.com/549706-lock-file-in-asp-net