Static methods in ASP.Net

[blah, blah, blah]

I'm developing a .Net web application and created many helper classes
often using static (shared in VB.Net) methods. Do I need to use the lock
(SyncLock) statement in these methods to prevent multiple web application
threads from using the same method at the same time?

For example, I have a static method that extracts information from a page
request cookie for use by other parts of the application. Since this
happens on every request I thought it would be a waste of resources to
create a new object just to provide the cookie method, so I made it
static. But then I thought if two different requests come into the
application milliseconds apart and two different threads request the same
static cookie method it could cause problems. The method is fast so it is
unlikely multiple threads will have a synchronization problem, but it
could happen (right?) and I do have other static methods take longer to
execute.

I'm not spawing a new thread to do any asynchronous processing, but it is
my understanding that IIS and ASP.Net are inherently multi-threaded when
dealing with page requests from different browsers/computers.

I've googled and searched all over the place but I can't find a clear
answer on if, when or how to use a lock statement in shared methods
specifically with web applications.

What are the general guidelines for using shared methods in web
applications?

Are there better methods for preventing synchronization problems than
using the lock statement?

Any pointers or tips are appreciated.
Dan

 

[Kevin Spencer]

It's not necessary to lock static methods.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[Scott Allen]

It's hard to say yes or no without knowing exactly what you are doing.
If you posted some code that would be helpful.

I'd disagree with Kevin and say there are certainly static method
scenarios where you need locks to keep the application well behaved.

If each thread operates on data specific to the thread, then no locks
are needed. For example:

public static string GetCookieName(Cookie c)
{
return c.Name;
}

If, on the other hand, multiple threads can access a shared object,
you need to be very careful:

static ArrayList cookieList = new ArrayList();

public static void AddToCookieList(Cookie c)
{
cookieList.Add(c);
}

No matter how fast the above method looks, the chance of corruption
exists because it doesn't prevent multiple threads from getting inside
the Add method.

 

[Kevin Spencer]

Well, Scott, you're not really disagreeing with me, but clarifying my
remarks. You are correct, in that, if the static method accesses and
modifies external static data, yes, that data would have to be locked. I
just didn't point that out. Thanks for the clarification.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[blah, blah, blah]

Scott,

I assumed the warnings about threading synchronization when using the
static keyword automatically extended to methods as well as variables and
objects. Now it is clear(er) to me how things work. The variables and
parameters used by a method are thread safe unless those variables are
marked as static. Only then do you need to wrap the relevant code in a
lock statement.

Thanks for the explination.
Dan

 

[Jeff Louie]

Another approach is to pass immutable data objects or structures to the
static method.

Regards,
Jeff

Are there better methods for preventing synchronization problems than

using the lock statement?<


*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!