[Swift-devel] swift write once array/struct

[Tim Armstrong]

It just occurred to me - are you thinking about it in terms of some
actor-based or object-based model of concurrency?

- Tim

On 21 March 2015 at 11:30, Tim Armstrong <tim.g.armstrong at gmail.com> wrote:

> 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/00a608ee/attachment.html>