Using static methods in apotentially multithreaded environment

[Simon Harvey]

Hi all,

In my project I have made a number of helper methods static. As I understand
it, this will create the problem that multiple threads could access the
static method at the same time and interfere with one another.

My question is, for each static method, do I need to lock access to only one
call at a time? I've noticed that Microsofts Data Application block also
uses static methods for its data access calls - for example execute and
executeNonQuery etc. Should these methods be changed to only allow access by
a single thread at any given moment?


Perhaps there is an easier solution than this. A colleague of mine is
banging on about what a terrible performance hit this will cause but given
that the application is quite small I dont think that it will be much of a
problem.

Any suggestions on what to do would be very much appreciated.

Thank you all

Simon

 

[John Wood]

I don't believe static methods pose any more or any less of a problem than
non-static methods when it comes to threading. You still have to lock any
data in your class when there is the potential for multiple threads to be
accessing the data concurrently.

The overhead can be quite large, but this largely depends on the frequency
of calls, length of time in the call etc.

Please check out Jon Skeet's advice in
http://www.pobox.com/~skeet/csharp/multithreading.html for more information.

 

[Cor Ligthert]

Hi Simon,

In my opinion can when an object is instanced for only one class be no
problem at all with multithreading (when the object not access other static
members) however with static members I would advice you to look to the Jon
Skeet page wherefore John gave you the link already.

Cor

 

[Guest]

threading only becomes a problem if there's shared state. if you don't have any shared state, then it's thread safe.

 

[William Stacey [MVP]]

That is true. If no shared state, then don't need locking. If state set in
constructor and read only, then don't need locking. However, if shared rw
state, then you have to lock as normal - static does not change this
requirement. If most of your threads will be reads, then you may look into
a readerwriter lock instead of a monitor. However a rw lock is slower then
monitor, so you will have determine perf benefit to your app via testing.
Things like blocking, waits, etc can effect all this. If each thread only
grabs lock for short time without any waiting inside the lock, then Monitor
may be a better way to go. If your just updating and reading counters then
using Interlocked class instead of monitor could be used. However many
times you need to treat sets of vars atomically so they are consistent at
any give time in respect to other threads. Moreover, you also need to
determine if using multiple threads is actually going to increase
performance or decrease it. You may be able to refactor your model to avoid
the locks and get better perf with one thread. Or use a producer consumer
with shared queue in the middle. One thread produces at full blast and one
or more consumers can read objects as available. If your consumers will
block on same io anyway (such as a socket or file), one consumer may perform
better then many.

--
William Stacey, MVP

threading only becomes a problem if there's shared state. if you don't

have any shared state, then it's thread safe.

 

[Simon Harvey]

Hi All,

With regards to shared data, I have a Connection object and a command object
that is declared and used inside the static method. It is completely local.

Is this considered shared? I mean, is it shared by threads at the same time?

Also, is there a way to lock on a method rather than on a particular object.
Basically so you know that only one thread is in a method at a given moment?

Thanks for your help

Simon

 

[Cor Ligthert]

Hi Simon,

With regards to shared data, I have a Connection object and a command object
that is declared and used inside the static method. It is completely local.

Is this considered shared? I mean, is it shared by threads at the same time?

Also, is there a way to lock on a method rather than on a particular object.
Basically so you know that only one thread is in a method at a given

moment?

I think that it is much harder you can only use a command on a connection
for one process in a time (Net 1.1). So every thread has to wait untill the
other one is completly finished. So I think it is not wise to use a shared
method here.

However just my thought, and to point you on this problem.

Cor

 

[John Wood]

Local variables are created on the stack in the context of the calling
thread and are usually completely isolated from other threads calling the
same function.

You can lock on a method by having a sync object available that is only used
by that function. Just declare it as a static member of the class (even a
new object() would suffice).

 

[Guest]

Hi All,

With regards to shared data, I have a Connection object and a command object
that is declared and used inside the static method. It is completely local.

that is not shared. it's perfectly thread safe if they are all local.

 

[Richard A. Lowe]

Yes local connection and command objects should not be a problem.

Just as a note, you can use an attribute to lock a method without explicitly
creating a sync root object etc.
[System.Runtime.CompilerServices.MethodImpl(MethodImplOptions.Synchronized)]
public static void MyThreadedMethod()
{
// ...
}