<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:739868205;
        mso-list-template-ids:-1105798584;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1
        {mso-list-id:1161000415;
        mso-list-template-ids:1508563924;}
@list l1:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l2
        {mso-list-id:1753504987;
        mso-list-template-ids:784006286;}
@list l2:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l3
        {mso-list-id:2034963344;
        mso-list-type:hybrid;
        mso-list-template-ids:-1228131958 -1901422966 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l3:level1
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:-;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Calibri","sans-serif";
        mso-fareast-font-family:Calibri;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Let’s say I have two ArrayLists a and b.  I have multiple threads accessing them, protecting accesses to a and accesses to b with two separate ReadWriteLocks
 rwla and rwlb.  Since ArrayLists are (presumably) safe in sense 3, a program that guards all read accesses to a with rwla.readLock() guards all write accesses to a with rwla.writeLock(), and similarly for b, is well-synchronized, and hence guarantees sequential
 consistency, etc., just as if a and b were, say declared as double.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">This is an important property, which I think we assume all the time.  But there are other natural classes for which it doesn’t hold, e,g.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l3 level1 lfo4"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">         
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If a and b where completely unsynchronized splay trees.  The problem here is that two reads to a create a data race.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l3 level1 lfo4"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">         
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If ArrayList kept a global count of the total number of elements in all ArrayLists, and that count were not somehow synchronized.  In that case a
 write access to a in parallel with a write access to b would create a data race.  (This is contrived.  This usually happens in real life due to static caches, reference counting for copy optimization, or the like.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The current ArrayList spec implies by example that it is thread-safe in sense (3).  It would be nice if it could actually state that.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hans<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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""> Yuval Shavit [mailto:yshavit@akiban.com]
<br>
<b>Sent:</b> Tuesday, August 14, 2012 11:10 AM<br>
<b>To:</b> Boehm, Hans<br>
<b>Cc:</b> Joe Bowbeer; concurrency-interest<br>
<b>Subject:</b> Re: [concurrency-interest] Double Checked Locking in OpenJDK<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">I don't understand what you mean by scenario #3, then. What would a simple example look like, concretely?<o:p></o:p></p>
<div>
<p class="MsoNormal">On Tue, Aug 14, 2012 at 1:29 PM, Boehm, Hans <<a href="mailto:hans.boehm@hp.com" target="_blank">hans.boehm@hp.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In the setting that you describe, there is no ordering enforced between “modify ArrayList” and “read
 ArrayList”.  Hence (modulo one or two obscure corner cases that aren’t quite handled correctly), there is an alternate schedule in which they occur concurrently.  Hence there can be a high level data race on the ArrayList, and this is a client bug.  Don’t
 do that.  It is perfectly safe to use if you follow the rules and avoid the data race.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’m not sure I characterized 3 very well in a Java context, since Java built-in types sort-of have
 stronger properties.  A better characterization is probably “safely usable in code that doesn’t have high level data races on the class”.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hans</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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""> Yuval Shavit [mailto:<a href="mailto:yshavit@akiban.com" target="_blank">yshavit@akiban.com</a>]
<br>
<b>Sent:</b> Tuesday, August 14, 2012 7:03 AM<br>
<b>To:</b> Boehm, Hans<br>
<b>Cc:</b> Joe Bowbeer; concurrency-interest</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<b>Subject:</b> Re: [concurrency-interest] Double Checked Locking in OpenJDK<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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:<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">   - publish ArrayList to threads A and B<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">   - modify ArrayList (when A and B happen to not be reading it, but without locking to ensure that)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">   - A and B read ArrayList<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">... 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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">(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.)<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Mon, Aug 13, 2012 at 7:58 PM, Boehm, Hans <<a href="mailto:hans.boehm@hp.com" target="_blank">hans.boehm@hp.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p>I tend to think in terms of several useful levels of thread-safety:<o:p></o:p></p>
<p> <o:p></o:p></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.<o:p></o:p></p>
<p> <o:p></o:p></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.<o:p></o:p></p>
<p> <o:p></o:p></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.<o:p></o:p></p>
<p> <o:p></o:p></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.<o:p></o:p></p>
<p> <o:p></o:p></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.<o:p></o:p></p>
<p> <o:p></o:p></p>
<p>Hans<o:p></o:p></p>
<p> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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><o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
<b>Subject:</b> Re: [concurrency-interest] Double Checked Locking in OpenJDK<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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:<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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<o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
all public fields are final,<o:p></o:p></li></ul>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo2">
all public final reference fields refer to other immutable objects, and<o:p></o:p></li></ul>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo3">
constructors and methods do not publish references to any internal state which is potentially mutable by the implementation.<o:p></o:p></li></ul>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">--Joe<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Mon, Aug 13, 2012 at 2:46 PM, Wolfgang Baltes wrote:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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>
Wolfgang.</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
<br>
<br>
On 2012-08-13 13:20, Ruslan Cheremin wrote:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Ruslan Cheremin writes:><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">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><o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>