static classes & threading

  • Thread starter Thread starter Frank Rizzo
  • Start date Start date
F

Frank Rizzo

Hello,

I have a class with all static methods that is called by multiple
threads. I was wondering what effect that has on the competing threads.
Does Thread2 have to wait until Thread1 is done with the
StaticClass.Method1 before it can use it?

What if I removed static methods and made all the threads instantiate
its own copy of the class? Would that remove the waiting contention?

Thanks.
 
That's the whole point of multithreading :) So unless there is a
mutual-exclusion lock in your method the second thread will not wait for the
first thread to finish executing the static method.

Gabriel Lozano-Morán
Software Engineer
Sogeti
 
I am still not clear. Let's say the static method DoSomeTask creates a
connection object and gets some data, then destroys the connection.
Then let's say 2 threads call DoSomeTask. Will the second thread have
to wait for the first thread to complete?

Regards
 
No the second thread will also create a connection object and get some data
while the first thread is still getting some data. The difference between a
static method and a non-static method is that the static method belongs to
the type where the non-static method belongs to an instance of a class.

Gabriel Lozano-Morán
Software Engineer
Sogeti
 
Gabriel said:
No the second thread will also create a connection object and get some data
while the first thread is still getting some data. The difference between a
static method and a non-static method is that the static method belongs to
the type where the non-static method belongs to an instance of a class.
Click to expand...

Thank you. I am proceeding with the static method then.
 
If your entire class exists of static methods and properties consider
applying the Singleton design pattern.

Gabriel Lozano-Morán
Software Engineer
Sogeti
 
I think that your confusion (and ours) arises because you haven't
stated where you are storing your data. Threading problems don't crop
up based on whether you have static or instance methods. They crop up
based on whether the threads share data, or state.

If DoSomeTask creates a connection _and then stores that connection in
a static variable_ that is visible to other threads, then you'll have
contention problems and will have to introduce a lock. If, however,
DoSomeTask creates a connection and puts the reference to it in a local
variable (which would be on the stack), there is no interaction between
threads, because each thread has its own stack.

If your static class has static state as well, then you have to worry
about locks. If it has no state, there should be no threading problems
and no waiting.
 
I disagree. Unless there's a specific need for singleton, you shouldn't use
it just for the sake of using it. for example, it's perfectly fine to use a
class consist solely of static utility methods. In fact, I think singleton
is a poor choice here.
 
I agree that one shouldn't use a singleton just for the sake of using
it. However, when you end up with a static class with static state,
it's a pretty good indication that a singleton would be better.

As well, classes that do database operations may later come under the
re-engineering microscope if more that one data base needs to be
supported. You can't use polymorphism, interfaces, and the like using a
static class.

This particular case is a good one for a singleton. However, I agree
with Daniel that utility classes shouldn't be made singletons "just
because". (For a good example of a static class that should be a static
class, see "System.Math".)
 
"De gustibus et coloribus non est disputandum"

Let's just say that I would personally prefer using the singleton design
pattern over static members that can call other static members that can call
other static members, and so on.

Gabriel Lozano-Morán
Software Engineer
Sogeti
 
Bruce said:
I think that your confusion (and ours) arises because you haven't
stated where you are storing your data. Threading problems don't crop
up based on whether you have static or instance methods. They crop up
based on whether the threads share data, or state.

If DoSomeTask creates a connection _and then stores that connection in
a static variable_ that is visible to other threads, then you'll have
contention problems and will have to introduce a lock. If, however,
DoSomeTask creates a connection and puts the reference to it in a local
variable (which would be on the stack), there is no interaction between
threads, because each thread has its own stack.

If your static class has static state as well, then you have to worry
about locks. If it has no state, there should be no threading problems
and no waiting.
Click to expand...

That's correct - I am confused by what the threads actually use.
Let me give you an example. Let's say I have a static transaction
object. It is used by a non-static class method to insert some data.
If 2 threads were to have a go at this non-static method, would they
both use the static transaction object? And as a result, would there be
contention for that static transaction object?

Tbanks
 
Yes. If the data is static then there is only one of it, and two
threads attempting to access the same thing would require some sort of
locking, either within the implementation of the object or imposed by
the methods that use it.

Just so that you know, I'm no expert on multi-threading. There are
others here (such as Jon Skeet) who know far more than I do.

However, I can tell you that threading problems do not have to do with
instance methods vs static methods, but have to do with whether two
threads are going after the same piece of data at the same time.

(To illustrate further, there is no danger in two threads calling the
same instance method in the same object if that method never refers to
static variables and never refers to "this." anything--never looks at
static state or the object's state. Since the two threads aren't trying
to play with the same data items at the same time, no problems.)

In your case, if you have one shared transaction object, you could
easily run into the (classic) problem in which the two threads try to
both create the transaction object:

if (transaction == null)
{
transaction = new Transaction();
}

or something like that. If both threads run the "if" test at the same
time, they will both discover that there is no transaction object
available, and they will both create a new Transaction, the later one
clobbering the Tranasaction created by the earlier one.

Again, the problem isn't really that they're running the same code. The
problem is that they are testing / manipulating the same (shared) data
at the same time.
 
Thanks, Bruce. That's what I thought and this fully clears it up for
me. Back to instance methods & properties.
 
Frank said:
Thanks, Bruce. That's what I thought and this fully clears it up for
me. Back to instance methods & properties.
Click to expand...

Just for the record, using only instance methods and properties is no
guarantee of thread safety. If two threads happen to be using the same
object (class instance), you'll still have the same problem.

Obviously, you can prevent that from ever happening (by making sure no two
threads get the same object), but if it ever did happen...

--
Reginald Blue
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."
- Bjarne Stroustrup (originator of C++) [quoted at the 2003
International Conference on Intelligent User Interfaces]
 
So would you argue for the System.Math class to be reimplemented as a singleton?

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

"De gustibus et coloribus non est disputandum"

Let's just say that I would personally prefer using the singleton design
pattern over static members that can call other static members that can call
other static members, and so on.

Gabriel Lozano-Mor?n
Software Engineer
Sogeti
 
I think that the OP had the opposite impression: that using static
methods and static fields was a guarantee of thread safety. He now
knows that it's not.
 
If you really think about it a class containing nothing but static members
is already an implementation of the singleton design pattern but with more
limitations than a full blown implementation of the singleton.

Gabriel Lozano-Morán
 
Got agree with Bruce here. I do not understand your point. What *exactly*
would be gained by making System.Math a singleton?

I personally use the singleton pattern when I need to cache system wide
data, and ensure only one copy of that data is available through a central
source.
 
Back
Top