<div dir="ltr">Thanks Mihael, that clarifies it.<div><br></div><div>Tim, I was thinking from the point of view of avoiding deadlocks. I understand the semantics would remain same. I was thinking a self contained array/struct in terms of state management (may be it is called actor based impl, not sure) would be more robust in terms of avoiding deadlocks.</div><div><br></div><div>--</div><div>Ketan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 21, 2015 at 12:28 PM, Hategan-Marandiuc, Philip M. <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, 2015-03-21 at 10:38 -0500, Ketan Maheshwari wrote:<br>
> Hi Tim,<br>
><br>
> Thanks for the clarification and code snippet. To clarify, in my<br>
> understanding, the implementation is 'extrinsic'.<br>
><br>
> To be intrinsic, I imagined the array is implemented as an object which has<br>
> a function that monitors and controls its write-once property and gets<br>
> invoked every time anything is written to any element of the array.<br>
<br>
</span>The array is implemented as you describe above. I'm not really sure what<br>
extrinsic would be.<br>
<br>
Calls to an object's methods aren't automatically synchronized or<br>
atomic, so I don't think that assumption in your earlier email is<br>
correct.<br>
<br>
Even if they were, having this particular method atomic does not<br>
guarantee that there would be no deadlocks. A user can write a[0] =<br>
f(a[1]); a[1] = f(a[0]);<br>
<br>
Mihael<br>
<br>
</blockquote></div><br></div>