By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,538 Members | 1,130 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,538 IT Pros & Developers. It's quick & easy.

static methods and race conditions

P: n/a
One of my coworkers insists that one should never use
static methods because race conditions exist. Thinking
along the lines that all variable assignments are
assignments to static variables.

He's wrong. Right?

Two users in a web session could both access a static
method at the same time and never have any trouble.

Right?
Jul 17 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a

"GIMME" <gi*******************@yahoo.com> wrote in message
news:3f**************************@posting.google.c om...
One of my coworkers insists that one should never use
static methods because race conditions exist. Thinking
along the lines that all variable assignments are
assignments to static variables.

He's wrong. Right?

Two users in a web session could both access a static
method at the same time and never have any trouble.

Right?


Static or not has nothing to do with it. Race conditions can only occur in
multithread environments, such as in servlet code where the servlet
container could handle multiple requests through the same object instances
at the same time.

Accessing the same object from multiple threads simultaneously can be a
problem but does not have to be. If for example two threads perform
simultaneous access to an object without changing its state that would be
fine. If they do change the state and the state transition involves instable
intermediate states a problem could arise. To prevent such problems Java has
constructs like the synchronized keyword and wait/notify.

Silvio Bierman
Jul 17 '05 #2

P: n/a
class Problematic
{
static int x;

static void method(int x)
{
Problematic.x = x;
}
}

/*
This is problematic (in a multi-threaded environment) because, if two
threads call the method, there is access to
shared data (Problematic.x), and therefore, a race condition exists.
However, the simple generalization that "static methods have race
conditions" is clearly incorrect and is likely the result
of misinterpreting some document.
*/

class Fine
{
static void method(int x)
{
System.out.println(x);
}
}

/*
This is fine to call the method from multiple threads, since the
method-local x is placed on the method call stack
*/

class Problematic
{
static void method(SomeMutableType smt)
{
// change smt
}
}

/*
Again, there is access to (and altering of) shared data (the object referred
to that is passed when the method is called), and thus, a problem exists.
*/
--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software

"Silvio Bierman" <sb******@idfix.nl> wrote in message
news:3f*********************@news.xs4all.nl...

"GIMME" <gi*******************@yahoo.com> wrote in message
news:3f**************************@posting.google.c om...
One of my coworkers insists that one should never use
static methods because race conditions exist. Thinking
along the lines that all variable assignments are
assignments to static variables.

He's wrong. Right?

Two users in a web session could both access a static
method at the same time and never have any trouble.

Right?
Static or not has nothing to do with it. Race conditions can only occur in
multithread environments, such as in servlet code where the servlet
container could handle multiple requests through the same object instances
at the same time.

Accessing the same object from multiple threads simultaneously can be a
problem but does not have to be. If for example two threads perform
simultaneous access to an object without changing its state that would be
fine. If they do change the state and the state transition involves

instable intermediate states a problem could arise. To prevent such problems Java has constructs like the synchronized keyword and wait/notify.

Silvio Bierman

Jul 17 '05 #3

P: n/a
Thanks Tony and Silvio.

Just to be sure ...

class IsThisOK
{
static String go( String A )
String a = A
return a;
}

}

Can to processes assign little a in a race condition
and mess things up for one of the users?
Jul 17 '05 #4

P: n/a
gi*******************@yahoo.com (GIMME) wrote in message news:<3f**************************@posting.google. com>...
Thanks Tony and Silvio.

Just to be sure ...

class IsThisOK
{
static String go( String A )
String a = A
return a;
}

}

Can to processes assign little a in a race condition
and mess things up for one of the users?

It depends on the context of how you use it--namely what is considered
an error.

Two threads could run this at exactly the same time a could be
reassigned by a different thread before the return statement is
executed by the first.

Assuming this would be problematic, there are two options:

1. Avoid assigning things in a static function if in a multithreaded
environment if it isn't really necessary. In other words, eliminate
the critical section.

2. Prevent multiple threads from using the critical section
concurrently. Use a monitor or some other mutex.

---
Jared Dykstra
http://www.bork.org/~jared
Jul 17 '05 #5

P: n/a
gi*******************@yahoo.com (GIMME) wrote in message news:<3f**************************@posting.google. com>...
One of my coworkers insists that one should never use
static methods because race conditions exist. Thinking
along the lines that all variable assignments are
assignments to static variables.

He's wrong. Right?

Two users in a web session could both access a static
method at the same time and never have any trouble.

Right?

Static methods in themselves are not a problem, unless they depend
upon data outside of the local scope. This is the same for regular
methods too.

In general the same race condition issues arise for static methods in
a class as for 'regular' methods in a single object instance. You need
to be just as careful calling a Class' static methods from two threads
as calling an object's regular methods from two threads (and not
necessarily the same method either!)
-FISH- ><>
Jul 17 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.