[Swift-devel] swift write once array/struct

[Mihael Hategan]

One more comment.

This is not a deadlock that comes from a faulty implementation, so
better software engineering won't fix it.

This is an algorithmic issue in that the language allows more
flexibility that the algorithms implementing it can analyze to determine
when something that is theoretically deadlock-free would in practice be
deadlock-free. So there are corner cases where the implementation fails
not because of something that was missed, but because I don't quite know
how to do it better.

Mihael

On Sat, 2015-03-21 at 14:16 -0500, Ketan Maheshwari wrote:
> Thanks Mihael, that clarifies it.
> 
> 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.
> 
> --
> Ketan
> 
> On Sat, Mar 21, 2015 at 12:28 PM, Hategan-Marandiuc, Philip M. <
> hategan at mcs.anl.gov> wrote:
> 
> > On Sat, 2015-03-21 at 10:38 -0500, Ketan Maheshwari wrote:
> > > Hi Tim,
> > >
> > > Thanks for the clarification and code snippet. To clarify, in my
> > > understanding, the implementation is 'extrinsic'.
> > >
> > > To be intrinsic, I imagined the array is implemented as an object which
> > has
> > > a function that monitors and controls its write-once property and gets
> > > invoked every time anything is written to any element of the array.
> >
> > The array is implemented as you describe above. I'm not really sure what
> > extrinsic would be.
> >
> > Calls to an object's methods aren't automatically synchronized or
> > atomic, so I don't think that assumption in your earlier email is
> > correct.
> >
> > Even if they were, having this particular method atomic does not
> > guarantee that there would be no deadlocks. A user can write a[0] =
> > f(a[1]); a[1] = f(a[0]);
> >
> > Mihael
> >
> >