About a month or so ago, I started trying to convert a codebase I've been working on into a multithreaded system, and I've been hitting this sort of thing over and over:<div>--------</div><div>// used as a field and as a local variable all over the codebase</div>

<div><div>struct Data {</div><div><span class="Apple-tab-span" style="white-space:pre">       </span>int a,b,c;</div><div><span class="Apple-tab-span" style="white-space:pre">   </span></div><div><span class="Apple-tab-span" style="white-space:pre">     </span>int total() {</div>

<div><span class="Apple-tab-span" style="white-space:pre">              </span>return a + b + c;</div><div><span class="Apple-tab-span" style="white-space:pre">    </span>}</div><div>}</div><div><br></div><div>// has a Data as one of its members but never escapes a pointer to it</div>

<div>class Bob {</div><div><span class="Apple-tab-span" style="white-space:pre">    </span>private:</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>Data _dat;</div><div><span class="Apple-tab-span" style="white-space:pre">   </span></div>

<div><span class="Apple-tab-span" style="white-space:pre">      </span>public:</div><div><span class="Apple-tab-span" style="white-space:pre">      </span>int currentTotal() {</div><div><span class="Apple-tab-span" style="white-space:pre">         </span>return _dat.total();</div>

<div><span class="Apple-tab-span" style="white-space:pre">      </span>}</div><div>}</div></div><div>--------</div><div>Now, as part of my multithreaded refactor, I need to make Bob synchronized, but that means the Data field inside it is shared, which means I can no longer call the total() method in currentTotal().</div>

<div>To fix this, I could make Data synchronized as well, but Data is used all over the codebase, most of the time as a local variable inside a function. In my particular case, I see this a lot with a struct that represents a location, which is just 2 bytes in my codebase, so adding a monitor would more than double the size, and the locking overhead would be completely unnecessary.</div>

<div>If I don't want to make it synchronized, I could just cast away shared everywhere I use it as a field, which looks ugly and is confusing when I look at the codebase.</div><div>If I don't want to cast away shared, I could just make Data shared and assume that the owner will make sure it's not shared improperly, but at this point I've disabled all help the type system could provide me.</div>

<div><br></div><div>Firstly, according to TDPL:</div><div>--------</div><div>For synchronized methods:</div><div>"Maybe not very intuitively, the temporary nature of synchronized entails the rule that no address of a field can escape a synchronized address. If that happened, some other portion of the code could access some data beyond the temporary protection conferred by method-level synchronization."</div>

<div><br></div><div>For synchronized classes:</div><div><div>• All numeric types are not shared (they have no tail) so they can be manipulated normally.</div><div>• Array fields declared with type T [ ] receive type shared(T) [ ] ; that is, the head (the slice limits) is not shared and the tail (the contents of the array) remains shared.</div>

<div>• Pointer fields declared with type T* receive type shared(T)*; that is, the head (the pointer itself) is not shared and the tail (the pointed-to data) remains shared.</div><div>• Class fields declared with type T receive type shared(T). Classes are automatically by-reference, so they're "all tail."</div>

<div>These rules apply on top of the no-escape rule described in the previous section.</div><div>One direct consequence is that operations affecting direct fields of the object can be freely reordered and optimized inside the method, as if sharing has been temporarily suspended for them—which is exactly what synchronized does.</div>

</div><div>--------</div><div><br></div><div>At a first glance, it seems like the first rule should apply for structs (which would mean it should address "value types"), but it can't because a struct could contain a reference to another object, and that reference should be transitively shared. Typing a struct as shared if it contains a reference and unshared otherwise would just be confusing, but this use case is one that the language does not currently address in a satisfying way.</div>

<div><br></div><div>When I flag a type as shared, all instances of it are forced to become shared, but the compiler assumes that the programmer has properly synchronized things such that sharing instances of the type is safe. Why, then, can I not force the compiler to assume I've properly synchronized things for a field of a class? In this case, the effect would be the opposite - the field wouldn't be flagged as shared, but supposing we had such a keyword, it would act as a much more limited version of the "shared" keyword because I'm only forcing the compiler to assume I've done things properly within the context of a class.</div>

<div>The keyword would have to be restricted such that it could only be applied to private fields, and the compiler would continue to enforce (as much as is reasonable) that the address of the field does not escape.</div>

<div><br></div><div>I believe that this case of data sharing will appear and frustrate programmers in almost any multithreaded program, and that finding a satisfying solution to allow the language to provide as many guarantees as possible is worthwhile.</div>

<div><br></div><div>Any thoughts?</div>