Threads and statics

[Dirk Bruere at NeoPax]

Is there a problem with multiple threads using the same static method of
a class?

 

[Robert Klemme]

The local variables for a method go on the calling thread's stack,
regardless of whether the method is static or not.

Static data presents the same issues when accessed from a static method
as when accessed from non-static methods.

I would word it differently: shared mutable state presents concurrency
issues if not properly synchronized. Whether the data is stored in a
static variable or a member variable (or even a database outside the
JVM) does not really matter for the concurrency implications.

Kind regards

robert

 

[Lew]

I would word it differently: shared mutable state presents concurrency
issues if not properly synchronized.  Whether the data is stored in a
static variable or a member variable (or even a database outside the
JVM) does not really matter for the concurrency implications.

You'd be wording a different "it". The problems go beyond concurrency
issues. They can present in single-threaded code, too.

For example, the dreaded 'java.util.ConcurrentModificationException'
is not limited to multithreaded scenarios.

 

[markspace]

Is there a problem with multiple threads using the same static method of
a class?

Yes. There's a problem with anything involving multiple threads, if you
do it wrong.

We'll need an SSCCE to help you more. Meantime, Google for
Java+concurrency.

<http://download.oracle.com/javase/tutorial/essential/concurrency/>

 

[Arved Sandstrom]

You'd be wording a different "it". The problems go beyond concurrency
issues. They can present in single-threaded code, too.

For example, the dreaded 'java.util.ConcurrentModificationException'
is not limited to multithreaded scenarios.

It's not, and in fact most occurrences of
ConcurrentModificationException I've seen are not in multi-threaded
situations, they are in single-threaded scenarios.

I sort of wish they'd come up with a different name than
ConcurrentModificationException; the exception usually has to do with
iterators in the presence of modification of the iterated thing, and the
name of the exception doesn't reflect that. If I don't have iterators
involved I can concurrently modify to my heart's content (although I
probably don't want to).

AHS
--
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

 

[Eric Sosman]

Is there a problem with multiple threads using the same static method of
a class?

No. There's also no problem with multiple threads using the
same instance method of a class, or even of a particular instance.

What matters is whether the methods use the same data. Static
or instance, it's the data-sharing that requires synchronization or
other special handling -- conversely, it's the non-sharing that
requires no care at all.

Advice that I found illuminating when first learning about
threading: Don't think about the code, think instead about the data
the code manipulates (more generally, about the "state" the code
manipulates). Make sure the data is always seen in a consistent
state, except perhaps by the *one* thread that's in the act of
changing it; then you'll have a correct program. (It might not be
the fastest possible program -- that's where the hard parts come
in -- but at least it won't have race conditions.)

 

[Stefan Ram]

manipulates). Make sure the data is always seen in a consistent
state, except perhaps by the *one* thread that's in the act of
changing it; then you'll have a correct program.

It still could have potential deadlocks.

IIRC, deadlocks can happen when two threads each need two
resources and already have obtained access to one of them.
Each thread now waits for the other one to release the
other resource.

I have little knowledge about multithreading, but from this
it seems that one can avoid deadlocks as long as one can
avoid situations where more than one resource needs to be
obtained for exclusive access at the same time.

From what I heard, for any realistic project, it is
impossible to be sure that one got this right. For example,
a program was written by experts in multithreading and then
showed a deadlock the first time after several years of use.

 

[Daniele Futtorovic]

I have little knowledge about multithreading, but from this
it seems that one can avoid deadlocks as long as one can
avoid situations where more than one resource needs to be
obtained for exclusive access at the same time.

That's a tautology. But there *are* cases where you need exclusive
access to more than one resource at the same time. The very fact that
multi-threaded programs exists proves one can avoid deadlocks in such
cases -- no need to look any further.

For example,
a program was written by experts in multithreading and then
showed a deadlock the first time after several years of use.

Beware of the "experts"!

 

[Stefan Ram]

That's a tautology. But there *are* cases where you need exclusive
access to more than one resource at the same time.

Inventing freely without knowledge, I would first try to pack
such resources into a single »meta resource«, which then can
be obtained or released by a single atomic action, again.

The very fact that multi-threaded programs exists proves one
can avoid deadlocks in such cases -- no need to look any
further.

Then, the existence of erroneous programs would prove what?

For the meaning of the verb »prove« in software engineering,
see for example this report:

http://machineslikeus.com/news/building-safety-nets-critical-systems

 

[Lew]

Inventing freely without knowledge, I would first try to pack
such resources into a single »meta resource«, which then can
be obtained or released by a single atomic action, again.

Then, the existence of erroneous programs would prove what?

For the meaning of the verb »prove« in software engineering,
see for example this report:

http://machineslikeus.com/news/building-safety-nets-critical-systems

.

The book /Java Concurrency in Practice/ (informally, JCIP) by Goetz, et al.,
shed light on these issues for me.

If there is a well-defined order of acquisition for multiple locks, you can
avoid deadlock. Trouble arises when acquirers act in different sequence,
e.g., one grabs A then B, whilst another grabs B then A.

One lock for multiple resources is another pattern in the book. It goes into
detail on how to reason about such scenarios.

 

[Eric Sosman]

manipulates). Make sure the data is always seen in a consistent
state, except perhaps by the *one* thread that's in the act of
changing it; then you'll have a correct program.

It still could have potential deadlocks. [...]

I also wrote, in the part you snipped

Deadlock is merely a performance problem. A really, Really,
REALLY bad performance problem.

 

[Mike Schilling]

manipulates). Make sure the data is always seen in a consistent
state, except perhaps by the *one* thread that's in the act of
changing it; then you'll have a correct program.

It still could have potential deadlocks. [...]

I also wrote, in the part you snipped

Deadlock is merely a performance problem. A really, Really,
REALLY bad performance problem.

There's a reason it's not call slightlyilllock.

 

[Tom Anderson]

manipulates). Make sure the data is always seen in a consistent
state, except perhaps by the *one* thread that's in the act of
changing it; then you'll have a correct program.

It still could have potential deadlocks. [...]

I also wrote, in the part you snipped

(It might not be
the fastest possible program -- that's where the hard parts come
in -- but at least it won't have race conditions.)

Deadlock is merely a performance problem. A really, Really,
REALLY bad performance problem.

There's a reason it's not call slightlyilllock.

It's only a fleshwoundlock!

tom

 

[Lew]

It's only a fleshwoundlock!

Caught between a rock and a hard place - it's a flintlock.