Except that, as I understand it, #3 doesn't exist. The non-threadsafe collections aren't threadsafe even if the only concurrent actions are read methods, because of memory visibility. Specifically, if you have:<div>

<br></div><div>   - publish ArrayList to threads A and B</div><div>   - modify ArrayList (when A and B happen to not be reading it, but without locking to ensure that)</div><div>   - A and B read ArrayList</div><div><br>
</div>
<div>... then that is *not* safe, because A and B are allowed to see only some of the action performed by step 2. For instance, maybe they see the list's size incremented, but don't see changes to its array. Or maybe they see everything in the ArrayList correctly, but don't see correct state in an object they read from it.</div>

<div><br></div><div>(I'm assuming that you meant by option #3 that there aren't concurrent writes, but that you don't enforce this via a lock. If you enforce it via a lock, you've externally synchronized the object and everything's fine... but in that case, the object's threadsafety-ness doesn't matter.)<br>

<br><div class="gmail_quote">On Mon, Aug 13, 2012 at 7:58 PM, Boehm, Hans <span dir="ltr"><<a href="mailto:hans.boehm@hp.com" target="_blank">hans.boehm@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">







<div lang="EN-US" link="blue" vlink="purple">
<div>
<p>I tend to think in terms of several useful levels of thread-safety:<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>1. Immutable, as defined below.  Untrusted code can create one, and it will always look the same to every observer.  There is no danger of a security check seeing one value and a later action seeing another.  Needed for String and the
 like.<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>2. "Thread-safe".  If I'm handed one by untrusted code, I shouldn't believe it.  But method calls are linearizable, and the right happens-before relationships are introduced.  I can assume such an object is not communicated via a race,
 since I don't care how it behaves with untrusted code.  A lot of j.u.c. classes fit here, I think, as does Vector.<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>3. "Behaves like built-ins".  Concurrent calls to "read" methods or to different objects behave correctly.  Concurrent calls on the same object, when at least one logically modifies the object is a bug.  Normal default behavior for ordinary
 collections, e.g. ArrayList, though many of them may have some additional, more specific, guarantees.  The client protects these with locks, as would an int.<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>4. Really, seriously thread-unsafe.  Accesses static fields behind the scenes without locking, modifies the data structure for logically read-only operations (think splay trees), etc.<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>I think all of those are useful.  (In particular, 3 is incredibly useful, and really needs a better name.)  I'm not sure how many more are.<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>Hans<u></u><u></u></p>
<p><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:concurrency-interest-bounces@cs.oswego.edu" target="_blank">concurrency-interest-bounces@cs.oswego.edu</a> [mailto:<a href="mailto:concurrency-interest-bounces@cs.oswego.edu" target="_blank">concurrency-interest-bounces@cs.oswego.edu</a>]
<b>On Behalf Of </b>Joe Bowbeer<br>
<b>Sent:</b> Monday, August 13, 2012 3:02 PM<br>
<b>To:</b> concurrency-interest</span></p><div class="im"><br>
<b>Subject:</b> Re: [concurrency-interest] Double Checked Locking in OpenJDK<u></u><u></u></div><p></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">For completeness, here is the documentation for the @Immutable annotation from JCiP, which is more heavily laden than the standard definition, and leaves nothing to the imagination of paranoid programmers:<u></u><u></u></p>

<div><div class="h5">
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="http://jcip.net/annotations/doc/net/jcip/annotations/Immutable.html" target="_blank">http://jcip.net/annotations/doc/net/jcip/annotations/Immutable.html</a><u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The class to which this annotation is applied is immutable. This means that its state cannot be seen to change by callers, which implies that<u></u><u></u></p>
<ul type="disc">
<li class="MsoNormal">
all public fields are final,<u></u><u></u></li></ul>
<ul type="disc">
<li class="MsoNormal">
all public final reference fields refer to other immutable objects, and<u></u><u></u></li></ul>
<ul type="disc">
<li class="MsoNormal">
constructors and methods do not publish references to any internal state which is potentially mutable by the implementation.<u></u><u></u></li></ul>
<p class="MsoNormal"><br>
Immutable objects may still have internal mutable state for purposes of performance optimization; some state variables may be lazily computed, so long as they are computed from immutable state and that callers cannot tell the difference.<br>


Immutable objects are inherently thread-safe; they may be passed between threads or published without synchronization.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">--Joe<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Mon, Aug 13, 2012 at 2:46 PM, Wolfgang Baltes wrote:<u></u><u></u></p>
<p class="MsoNormal">Immutability and thread safety should be considered essentially orthogonal concepts. However, the final keyword can be useful in both.<br>
<br>
Immutability just means that the object cannot be changed after instantiation. There are several ways to achieve this, the most obvious ones are a) to make a data fields final, and b) not to provide a method that changes the values of data fields.<br>


<br>
Thread safe publishing means that, when an object reference is shared between threads, all threads see the object only in the same state as the thread which has last modified (or instantiated) the object. There are different ways to accomplish this, the most
 obvious ones being to declare a fields final or volatile. Final provides the guarantee that a field can safely be published to other threads after the constructor that assigns the value is finished. If there are multiple fields, than only those that are marked
 final are covered by the guarantee. This is different from volatile, where instructions - such as writes to non volatile fields - that appear in the code before a write to a volatile field, are guaranteed to be executed before the first subsequent read of
 that volatile field, no matter in which thread this read instruction occurs. In the latter case, a non volatile field which is never modified by any method may also appear as immutable and be published in a thread safe manner.<br>


<br>
Hence, marking a field final makes it immutable and publishable in a thread safe manner, if the reference to the object that holds the field is published after the constructor is finished.<span style="color:#888888"><br>


<br>
<span>Wolfgang.</span></span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
On 2012-08-13 13:20, Ruslan Cheremin wrote:<u></u><u></u></p>
<p class="MsoNormal">Yes, and it is my point -- it's confusing to say "immutable" (which<br>
form of?), confusing to say "thread safe" (in which multithreaded use<br>
case it is safe?) and even more confusing to say both "immutable and<br>
thread-safe" -- because actually there is (==I know) only two ways to<br>
reach thread-safe immutability in java: "all fields final", or "all<br>
methods sync-ed, including constructors" -- and the second one is very<br>
rare.<br>
<br>
For me "immutable and thread safe" seems to be equivalent to<br>
"thread-safe immutable", which, in turn, implies safety for data race<br>
publication. How can I claim object as "thread safe immutable", if I<br>
can see in several states in multithreaded env.?<br>
<br>
<br>
2012/8/13 Yuval Shavit:<u></u><u></u></p>
<p class="MsoNormal">This class is immutable but not thread-safe absent safe publication:<br>
<br>
public class MyImmutable {<br>
     private long val; // not marked final or volatile<br>
     public MyImmutable(long val) {<br>
         this.val = val;<br>
     }<br>
<br>
     public int getValue() {<br>
         return val;<br>
     }<br>
}<br>
<br>
In the absence of safe publication, a thread is allowed to see:<br>
<br>
     - val's default value (0)<br>
     - the value passed to the constructor<br>
     - a word tear in which val contains only the high or low word from the<br>
value passed to the constructor<br>
<br>
<br>
On Mon, Aug 13, 2012 at 3:39 PM, Ruslan Cheremin wrote:<u></u><u></u></p>
<p class="MsoNormal">For me it is confusing: java has only one way to have really immutable<br>
object, and this way also gives you a total thread safety even for<br>
data race based publication. But then docs refer object as "immutable<br>
and thread-safe" -- we still can't assume it to be really thread-safe?<br>
<br>
It's a pity, especially because true immutability gives us some<br>
chances of performance optimization. As in this case -- we do not<br>
really need .path to be volatile here, if we would assume Path to be<br>
truly immutable. volatility here required only for ensuring safe<br>
publishing.<br>
<br>
2012/8/13 David Holmes:<u></u><u></u></p>
<p class="MsoNormal">Ruslan Cheremin writes:><u></u><u></u></p>
<p class="MsoNormal">But is there a way to define "safe for data race publishing"? I as<br>
far, as I remember, "immutable and thread-safe" is standard mantra in<br>
JDK javadocs for totally safe objects. j.l.String has same mantra --<br>
and it is safe for any way of publishing. Does you mean, I should<br>
explicitly add "safe even for publishing via data race" in docs? But I<br>
can't remember any such phrase in JDK docs.<u></u><u></u></p>
<p class="MsoNormal">I don't recall anything in the JDK docs that mention being "totally<br>
safe"<br>
regardless of publication mechanism. Some classes, eg String, have been<br>
defined such that they do have that property (for security reasons). In<br>
general neither "thread-safe" nor "immutable" imply<br>
safe-for-unsynchronized-publication.<br>
<br>
Java Concurrency In Practice (<a href="http://jcip.net" target="_blank">jcip.net</a>) does define additional potential<br>
annotations, where @Immutable would indeed capture the requirement of<br>
safe-for-unsynchronized-publication.<br>
<br>
David<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><u></u> <u></u></p>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</div>
</div>
</div>
</div>
</div></div></div>
</div>
</div>

<br>_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
<br></blockquote></div><br></div>