[Swift-devel] swift write once array/struct

[Tim Armstrong]

I still don't fully understand what distinction you're drawing.  Your
example seems functionally identical to the Swift/T example - on all
codepaths where an array cell might be written, the code checks whether or
not it was previously assigned before the second assignment happens.

>From the point of view of language semantics, the only relevant question is
"what happens when an array cell is assigned twice".

1. We can't always/don't detect it at compile time, so the program still
runs.
2. The first assignment A[i] = x; completes fine
3. Any reads before the second assignment return x;
4. The second assignment A[i] = y; causes a runtime error and stops the
program immediately

It's possible that the assignments happen in the opposite order, so x and y
can be swapped.

I'm not sure how the implementation details, e.g. how it's divided into
objects, matters so long as it implements the above semantics correctly.
Is the question whether the second assignment atomically causes a runtime
error?  It does in the current implementation.

- Tim



On 21 March 2015 at 10:38, Ketan Maheshwari <ketan at mcs.anl.gov> 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.
>
> Very rudimentary code below to clarify the idea:
>
> bool checklock(val_t val){
>   if (self.item) return ERRNOWRITE;
>   dowrite(self.item, val);
>  return OK;
> }
>
> About Swift semantics work: thanks, I will try to take a look and comment
> if I can.
>
> --
> Ketan
>
> On Sat, Mar 21, 2015 at 10:14 AM, Tim Armstrong <tim.g.armstrong at gmail.com
> > wrote:
>
>> Also, if you're curious about semantics of Swift data structures I've
>> been doing some work on that recently, would be happy to talk about it in
>> more detail.
>>
>> - Tim
>>
>> On 21 March 2015 at 10:06, Tim Armstrong <tim.g.armstrong at gmail.com>
>> wrote:
>>
>>> Hi Ketan,
>>>   I'm not sure that I fully understand the distinction between
>>> internal/external implementation.  In terms of externally observable
>>> behaviour, writing an already written cell will cause a runtime error
>>> immediately.  There's no way you can cause a deadlock or observe
>>> inconsistent values.  Deadlocks with array cells should only happen if
>>> something is waiting for a cell that has been assigned 0 times.
>>>
>>> If you're curious, i copied and pasted the relevant code fragment for
>>> Swift/T (it's in data.c in lb).  It's relatively straightforward, even
>>> though it's handling a few cases.  Essentially it's if (A[i] exists)
>>> return error code;.  The data structure is only accessed by a single
>>> thread so no race conditions are possible.
>>>
>>> I believe there's something similar in swift/k.
>>>
>>> - Tim
>>>
>>>       // Does the link already exist?
>>>       adlb_container_val t = NULL;
>>>       bool found = container_lookup(c, curr_sub, &t);
>>>
>>>       if (found && (value == NULL || t != NULL))
>>>       {
>>>         // Can overwrite reserved (unlinked) entries with actual data,
>>> but
>>>         // cannot double reserve entries.
>>>
>>>         // Don't print error by default: caller may want to handle
>>>         DEBUG("already exists: "ADLB_PRIDSUB,
>>>               ADLB_PRIDSUB_ARGS(id, d->symbol, subscript));
>>>         return ADLB_DATA_ERROR_DOUBLE_WRITE;
>>>       }
>>>       // Following code actually assigns the array cell
>>>       ...
>>>
>>>
>>>
>>>
>>>
>>> On 20 March 2015 at 23:33, Ketan Maheshwari <ketan at mcs.anl.gov> wrote:
>>>
>>>> Hi,
>>>>
>>>> So, in the meeting today, I was curious about wether the Swift write
>>>> once array/struct property is enforced via some external function or is it
>>>> intrinsic to the array/struct.
>>>>
>>>> In other words, is  the array/struct implemented in such a way that it
>>>> will automatically not allow anything to write once its i-th item has been
>>>> written or some external entity keeps track of this property and gets
>>>> triggered every time a write happens.
>>>>
>>>> I thought with intrinsic property, write operations will be atomic and
>>>> free of deadlocks as opposed to externally tracked/enforced property.
>>>>
>>>> --
>>>> Ketan
>>>>
>>>> _______________________________________________
>>>> Swift-devel mailing list
>>>> Swift-devel at ci.uchicago.edu
>>>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Swift-devel mailing list
>> Swift-devel at ci.uchicago.edu
>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150321/e2269dba/attachment.html>