Re: Safety Of Non-Synchronized Collections
markspace wrote:
Lew wrote:
http://rayfd.me/2007/11/11/when-a-synchronized-class-isnt-threadsafe/
This is elementary concurrency gotcha lore.
Note this sentence from the article: "Changing the synchronized List to
Vector doesn't help either."
Exactly! MY POINT!
Vector is thread safe. Objects wrapped by Collections.synchronized()
'Vector' is *not* thread safe!
That's the point of that article.
are thread safe. This does not guarantee that every use of those
classes is safe, or correct.
Their example is of a single collection which is accessed by multiple
threads. As they show their example produces errors. This is an issue
of atomicity, not thread safety. The single collection is still
It is an issue with the idea that people confuse synchronized methods with thread safety.
From the Brian Goetz article I quoted upthread:
"Thread-safe
Thread-safe objects have the properties described above in the section "Thread Safety" -- that
constraints imposed by the class's specification continue to hold when the object is accessed by
multiple threads, regardless of how the threads are scheduled by the runtime environment, without any
additional synchronization. This thread-safety guarantee is a strong one -- many classes, like
Hashtable or Vector, will fail to meet this stringent definition."
perfectly safe, in spite of the errors. There are no data races.
There are synchronization issues because a person coding that way thinks the
synchronized-method class is thread safe when it isn't.
You, too, are pulling No True Scotsman, and I will still use Brian Goetz's definitions
over yours.
However, the program produces errors because it is poorly designed. It
requires atomicity, and synchronized methods don't provide that across
multiple method calls.
Because the class *is not thread safe*!
So the problem is really one of quibbling over terminology. Thread
Terminology matters. It's worth "quibbling". (Calling it by something pejorative
does not diminish its real importance.)
safety and atomicity both fall under the more general heading of
concurrency and concurrent programming. Thread safety and atomicity are
A.k.a., threads.
not the same thing. They overlap a bit, but not much, so it's best to
Again, look at the definition and stop changing it.
actually understand what is being discussed. In Java, thread safe means
an absence of data races, but that's all. It says nothing about
atomicity, or the correctness of any given program.
Your definition is wrong.
--
Lew