How do I use the Java API in a Thread-Safe Manner?

[Thomas G. Marshall]

Bjorn Borud coughed up:

[[email protected]]

This doesn't help you now, but inside sources tell me that Doug Lea
and several other people are working on a new book that they think
will be out in December; it's not an update to or a follow-on to
"Concurrent Programming in Java" but instead something aimed more
at working programmers (if I understand it right). Working title
is "Java Concurrency in Practice". "FYI", as they say.

that is great news! wonder if I can pre-order it on Amazon.com

turns out: one can, so I did:

http://www.amazon.com/exec/obidos/tg/detail/-/0321349601

interesting list of authors.

-Bjørn

I think the cover of bees is a good one. It's a great analogy. Including
the sting you can receive by not handling them carefully.

 

[Dale King]

Raymond DeCampo coughed up:

....[rip]...

In general, I would assume that static methods are thread safe. Any
static method that is not would be considered to be broken by any
reasonable software engineer.

But that would be a dangerous assumption to make.

A static method can easily be MT unsafe. Static methods usually manipulate
one or more class variables, and those could be mucked up just as easily as
[object] member variables can.

And in that case it is the responsibility of the writer of those static
methods to make sure it is MT safe. As Raymond says: "Any static method
that is not would be considered to be broken by any reasonable software
engineer." As a presumably reasonable software engineer, I would
consider it broken if it was not MT-safe or didn't document its unsafe-ness.

 

[Thomas G. Marshall]

Dale King coughed up:

Raymond DeCampo coughed up:

....[rip]...

In general, I would assume that static methods are thread safe. Any
static method that is not would be considered to be broken by any
reasonable software engineer.

But that would be a dangerous assumption to make.

A static method can easily be MT unsafe. Static methods usually
manipulate one or more class variables, and those could be mucked up
just as easily as [object] member variables can.

And in that case it is the responsibility of the writer of those
static methods to make sure it is MT safe. As Raymond says: "Any
static method that is not would be considered to be broken by any
reasonable software engineer." As a presumably reasonable software
engineer, I would consider it broken if it was not MT-safe or didn't
document its
unsafe-ness.

Sure, ok. Actually, I was unsure of whether or not I should post that,
because Raymod's post could be taken to several levels of extreme.
Depending upon his strict meaning, it might be a valid counter, for example,
to point out that *all* methods *should* be MT-safe, but you're right.

 

[Raymond DeCampo]

Raymond DeCampo coughed up:

...[rip]...

In general, I would assume that static methods are thread safe. Any
static method that is not would be considered to be broken by any
reasonable software engineer.

But that would be a dangerous assumption to make.

A static method can easily be MT unsafe. Static methods usually manipulate
one or more class variables, and those could be mucked up just as easily as
[object] member variables can.

In my experience, most static methods do *not* manipulate class-level
variables. Most are self contained. YMMV.

If you have static methods that do manipulate class variables, you
should consider rewriting the class to put such things in an instance.

Ray

 

[Patricia Shanahan]

Dale King coughed up:

Raymond DeCampo coughed up:

....[rip]...



In general, I would assume that static methods are thread safe. Any
static method that is not would be considered to be broken by any
reasonable software engineer.



But that would be a dangerous assumption to make.

A static method can easily be MT unsafe. Static methods usually
manipulate one or more class variables, and those could be mucked up
just as easily as [object] member variables can.

And in that case it is the responsibility of the writer of those
static methods to make sure it is MT safe. As Raymond says: "Any
static method that is not would be considered to be broken by any
reasonable software engineer." As a presumably reasonable software
engineer, I would consider it broken if it was not MT-safe or didn't
document its
unsafe-ness.

Sure, ok. Actually, I was unsure of whether or not I should post that,
because Raymod's post could be taken to several levels of extreme.
Depending upon his strict meaning, it might be a valid counter, for example,
to point out that *all* methods *should* be MT-safe, but you're right.

I wish Sun would apply to the Java API documents a policy it has
followed consistently for the Solaris man pages for several years,
required "MT-level" documentation. The MT-level documentation appears in
a fixed format, at the same place in each man page, so it is easy to
find and check.

For example, you can tell that the Solaris malloc is safe to use in
multithreaded code, but may not have much internal parallelism,
without any guesswork, because the malloc(3c) man page says its MT-level
is Safe.

A documented feature seems to me to be more likely to be implemented,
tested, and preserved during maintenance than an undocumented
presumption about how things ought to be done.

Patricia

 

[Thomas G. Marshall]

Patricia Shanahan coughed up:

Dale King coughed up:

Thomas G. Marshall wrote:

Raymond DeCampo coughed up:

....[rip]...



In general, I would assume that static methods are thread safe. Any
static method that is not would be considered to be broken by
any reasonable software engineer.



But that would be a dangerous assumption to make.

A static method can easily be MT unsafe. Static methods usually
manipulate one or more class variables, and those could be mucked
up just as easily as [object] member variables can.

And in that case it is the responsibility of the writer of those
static methods to make sure it is MT safe. As Raymond says: "Any
static method that is not would be considered to be broken by any
reasonable software engineer." As a presumably reasonable software
engineer, I would consider it broken if it was not MT-safe or didn't
document its
unsafe-ness.

Sure, ok. Actually, I was unsure of whether or not I should post
that, because Raymod's post could be taken to several levels of
extreme. Depending upon his strict meaning, it might be a valid
counter, for example, to point out that *all* methods *should* be
MT-safe, but you're right.

I wish Sun would apply to the Java API documents a policy it has
followed consistently for the Solaris man pages for several years,
required "MT-level" documentation. The MT-level documentation appears
in a fixed format, at the same place in each man page, so it is easy
to find and check.

For example, you can tell that the Solaris malloc is safe to use in
multithreaded code, but may not have much internal parallelism,
without any guesswork, because the malloc(3c) man page says its
MT-level is Safe.

A documented feature seems to me to be more likely to be implemented,
tested, and preserved during maintenance than an undocumented
presumption about how things ought to be done.

Yep. What I often use (out of clinical paranoia ) as the MT level
documentation is the java source.

It scares me that some of the java source is (as I've been informed here)
not honored by particular JVM's.

 

[Thomas G. Marshall]

Raymond DeCampo coughed up:

Raymond DeCampo coughed up:

...[rip]...

In general, I would assume that static methods are thread safe. Any
static method that is not would be considered to be broken by any
reasonable software engineer.

But that would be a dangerous assumption to make.

A static method can easily be MT unsafe. Static methods usually
manipulate one or more class variables, and those could be mucked up
just as easily as [object] member variables can.

In my experience, most static methods do *not* manipulate class-level
variables. Most are self contained. YMMV.

If you have static methods that do manipulate class variables, you
should consider rewriting the class to put such things in an instance.

Maybe, but your logic seems a little "cart before the horse" to me. If you
have a static method, chances are it is there just so you *can*
access/mutate class variables. Otherwise, there is probably little reason
to have it at all.

{shrug} YMMV too.

 

[Raymond DeCampo]

Raymond DeCampo coughed up:

Raymond DeCampo coughed up:

...[rip]...



In general, I would assume that static methods are thread safe. Any
static method that is not would be considered to be broken by any
reasonable software engineer.

But that would be a dangerous assumption to make.

A static method can easily be MT unsafe. Static methods usually
manipulate one or more class variables, and those could be mucked up
just as easily as [object] member variables can.

In my experience, most static methods do *not* manipulate class-level
variables. Most are self contained. YMMV.

If you have static methods that do manipulate class variables, you
should consider rewriting the class to put such things in an instance.

Maybe, but your logic seems a little "cart before the horse" to me. If you
have a static method, chances are it is there just so you *can*
access/mutate class variables. Otherwise, there is probably little reason
to have it at all.

Quite the opposite. Instance methods exist to manipulate instance
variables and state. If a method does not do this, it ought to be
static. Static methods are for routines that do not belong to a class
instance. For example, every method in the Collections class, every
method in the Arrays class, the various String.valueOf() methods, the
parseXxx() methods in the extensions of java.lang.Number, most of the
methods in SwingUtilities, etc.

Ray

 

[Dale King]

Dale King coughed up:

Raymond DeCampo coughed up:

....[rip]...



In general, I would assume that static methods are thread safe. Any
static method that is not would be considered to be broken by any
reasonable software engineer.



But that would be a dangerous assumption to make.

A static method can easily be MT unsafe. Static methods usually
manipulate one or more class variables, and those could be mucked up
just as easily as [object] member variables can.

And in that case it is the responsibility of the writer of those
static methods to make sure it is MT safe. As Raymond says: "Any
static method that is not would be considered to be broken by any
reasonable software engineer." As a presumably reasonable software
engineer, I would consider it broken if it was not MT-safe or didn't
document its
unsafe-ness.

Sure, ok. Actually, I was unsure of whether or not I should post that,
because Raymod's post could be taken to several levels of extreme.
Depending upon his strict meaning, it might be a valid counter, for example,
to point out that *all* methods *should* be MT-safe, but you're right.

I disagree that *all* methods should be MT-safe. It would hurt
performance greatly for very little gain.

There is however a distinction between instance and static methods in
this respect. That was all I was commenting on. When you create an
object instance you have a level of control over whether multiple
threads can even access it by controlling whether they actually have
access to the object reference itself. The same cannot be said about
static methods. You have almost no control over whether a thread can
call a static method. Therefore static methods pretty much need to be MT
safe by default.

 

[Thomas G. Marshall]

Raymond DeCampo coughed up:

Raymond DeCampo coughed up:

Thomas G. Marshall wrote:

Raymond DeCampo coughed up:

...[rip]...



In general, I would assume that static methods are thread safe. Any
static method that is not would be considered to be broken by
any reasonable software engineer.

But that would be a dangerous assumption to make.

A static method can easily be MT unsafe. Static methods usually
manipulate one or more class variables, and those could be mucked
up just as easily as [object] member variables can.


In my experience, most static methods do *not* manipulate
class-level variables. Most are self contained. YMMV.

If you have static methods that do manipulate class variables, you
should consider rewriting the class to put such things in an
instance.

Maybe, but your logic seems a little "cart before the horse" to me. If
you have a static method, chances are it is there just so you
*can* access/mutate class variables. Otherwise, there is probably
little reason to have it at all.

Quite the opposite. Instance methods exist to manipulate instance
variables and state. If a method does not do this, it ought to be
static. Static methods are for routines that do not belong to a class
instance. For example, every method in the Collections class, every
method in the Arrays class, the various String.valueOf() methods, the
parseXxx() methods in the extensions of java.lang.Number, most of the
methods in SwingUtilities, etc.

Hmmmm.... that's an interesting perspective to raise in this particular
discussion: that if an instance method does not manipulate instance
variables and state then it ought to be static. Manipulate would of course
mean /both/ the accessing and mutation of them.

For variables alone, I don't really believe that is true. The "state" part
of what you said makes me uneasy. Take this example:

public class Corvette
{
public void announce() { System.out.println("I am a Corvette"); }
}

public class SledgeHammer extends Corvette
{
public void announce() { System.out.println("I am a SledgeHammer
modified Corvette"); }
}

The announce() methods *cannot* be static and still work polymorphically:

Corvette car = new SledgeHammer();
car.announce(); // announces "Corvette" only

Yet they do not access variables, nor state, unless you view state as built
into the announce() method.

 

[Raymond DeCampo]

Raymond DeCampo coughed up:

Raymond DeCampo coughed up:


Thomas G. Marshall wrote:


Raymond DeCampo coughed up:

...[rip]...




In general, I would assume that static methods are thread safe. Any
static method that is not would be considered to be broken by
any reasonable software engineer.

But that would be a dangerous assumption to make.

A static method can easily be MT unsafe. Static methods usually
manipulate one or more class variables, and those could be mucked
up just as easily as [object] member variables can.


In my experience, most static methods do *not* manipulate
class-level variables. Most are self contained. YMMV.

If you have static methods that do manipulate class variables, you
should consider rewriting the class to put such things in an
instance.



Maybe, but your logic seems a little "cart before the horse" to me. If
you have a static method, chances are it is there just so you
*can* access/mutate class variables. Otherwise, there is probably
little reason to have it at all.

Quite the opposite. Instance methods exist to manipulate instance
variables and state. If a method does not do this, it ought to be
static. Static methods are for routines that do not belong to a class
instance. For example, every method in the Collections class, every
method in the Arrays class, the various String.valueOf() methods, the
parseXxx() methods in the extensions of java.lang.Number, most of the
methods in SwingUtilities, etc.

Hmmmm.... that's an interesting perspective to raise in this particular
discussion: that if an instance method does not manipulate instance
variables and state then it ought to be static. Manipulate would of course
mean /both/ the accessing and mutation of them.

You've changed the subject. Of course methods designed to work
polymorphically or as part of an interface implementation cannot be made
static. But that is not the point of the discussion, that was merely a
reaction an explanation of part of the reasoning behind one of my
assumptions that does not go to the heart of the current topic.

The point is that I maintain that most static methods do not manipulate
class variables. I gave a slew of examples above. I further maintain
that any static method that is not thread safe should be considered
broken. Therefore is it reasonable to assume thread safety when dealing
with static methods. (That does not mean that you should not be aware
that no programmer is perfect and that bugs will happen.)

Ray