Is the following Java code thread safe?
public class TwoNumbers {
private int first;
private int second;
public void setNumbers(int first, int second) {
this.first = first;
this.second = second;
}
public int getFirst() { return first; }
public int getSecond() { return second; }
}
How about the following C++ code? Is the following C++ code thread safe?
class TwoNumbers {
private:
int first;
int second;
public:
TwoNumbers() : first(0), second(0) {}
void setNumbers(int first, int second);
int getFirst() { return first; }
int getSecond() { return second; }
}
void TwoNumbers::setNumbers(int first, int second)
{
this->first = first;
this->second = second;
}
I wish this were not just a rhetorical question. I'm curious to know what other developers think. You see, I don't believe the terminology is clear. I have a hunch that some developers would say that both the Java code and the C++ code are thread-safe, while other developers would say that the both the Java code and the C++ are not thread-safe. Not only that, I have a hunch that some developers, if I showed them the C++ code first, would say that that code is thread-safe, but if I then showed them the Java code, they might change their answer.
If you want my answer, I say that the code in both cases is thread-safe, because the classes contain only instance data and no class data.
Those developers who disagree with my answer would say that if two threads
call the setNumbers method at the same time, the data could be
set inconsistently. In other words, the code is not thread-safe because the
method is not synchronized. The conversation could move on from there to an
argument over just exactly what we mean when we say that code is
"thread-safe." But I wouldn't go there, because I know that the term
thread-safe is probably not well-defined, so there's no point in
arguing. And that's the point of this article.
I get support questions for MIME++, Mail++, and JMIME. Some developers ask the question: "Is your library thread-safe?" How am I supposed to answer that? What I want to know is this: What do you mean by thread-safe? Do you mean that all static data is protected against simultaneous access from different threads? Do you mean that the library calls only thread-safe functions in the C runtime library? Or do you mean that class methods are synchronized? My answer that developer's question ends up being much more than a simple "yes" answer. It's a "yes" answer with an explanation of exactly what that "yes" means.
For many programmers, I'm sure the concept of thread safety has
evolved. Back in the days of simple C APIs, the answer to the question
about thread safety was a clear "yes" or "no." If the functions in the API
did not use an static data or call any thread-unsafe functions in the C
runtime library, then the API was thread-safe. Otherwise, it was not. In
the C++ view of the world, things have not changed that much, because we
still understand a member function as a function with a hidden
this pointer argument. Therefore, clear-thinking developers
understand what thread safety means in a C++ API. But now, with Java having
introduced synchronized methods and classes such as
java.util.Vector that have only synchronized methods, I'm not
so sure that we know what thread-safe means. There are probably Java
developers who think that
java.util.Vector is thread-safe and
java.util.ArrayList is not.
Threads are both useful and dangerous. My worst nightmare is that someone would use one of Hunny Software's libraries in a multithreaded application, commit flagrant violations of thread best practices, and blame it all on our libraries. As far as I'm concerned, the answer to "Is it thread-safe?" is not a simple answer.
Posted by Doug Sauder at March 21, 2004 08:51 AM