[swift-users] Swift 4.0 bug in concurrent array access

[C. Keith Ray]

It's up to the  programmer-user to impose thread-safety around an array or other data structure. The compiler doesn't know if you want to allow multiple threads to write and read multiple array members, or prevent all but one thread to read and write multiple array members, or allow multiple readers when there are no writers, etc. (And we have queues precisely for these scenarios.)

The mutation counter detects if modifications happen while iterating over a collection, modifications like adding or removing members. When this happens, it's probably a programmer error. It's a bonus if this can be detected in a multiple thread scenario.

--
C. Keith Ray

* https://leanpub.com/wepntk <- buy my book?
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
* http://agilesolutionspace.blogspot.com/

> On Jan 8, 2018, at 6:25 PM, ‫Fadi Botros‬ ‫ via swift-users <swift-users at swift.org> wrote:
> 
> What about double checking?
> 
> 
> 
> Something like that
> 
> if counter != 0 { throw exc }
> counter += 1
> if counter != 1 { throw exc }
> counter += 1
> 
> I think the performance penalty is just a check and an increment
> It could be disabled after optimization or in release version to increase performance
> 
> 
> من: Greg Parker <gparker at apple.com>
> إلى: Chris Lattner <clattner at nondot.org> 
> نسخة كربونية: Jordan Rose <jordan_rose at apple.com>; swift-users <swift-users at swift.org>; ‫Fadi Botros‬ ‫ <botros_fadi at yahoo.com>
> تاريخ الإرسال: الثلاثاء 9 يناير، 2018‏ 3:47 ص
> الموضوع: Re: [swift-users] بخصوص: Swift 4.0 bug in concurrent array access
> 
> 
>>> On Jan 8, 2018, at 5:20 PM, Chris Lattner <clattner at nondot.org> wrote:
>>> 
>>>> On Jan 8, 2018, at 2:59 PM, Greg Parker via swift-users <swift-users at swift.org> wrote:
>>>> 
>>>>> On Jan 8, 2018, at 12:51 PM, Jordan Rose via swift-users <swift-users at swift.org> wrote:
>>>>> 
>>>>> On Jan 8, 2018, at 11:47, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_fadi at yahoo.com⁩> wrote:
>>>>> 
>>>>> 1st: How to invoke the thread sanitizer?
>>>> 
>>>> Check out this article on developer.apple.com: https://developer.apple.com/documentation/code_diagnostics/thread_sanitizer/enabling_the_thread_sanitizer
>>>> 
>>>>> 2nd: I think making something like ConcurrentModificationException of Java should be a little better experience (if it will not make, or make a small performance penalty, also if it makes performance penalty, it would be activated only when you make a debug version or non-optimized version)
>>>> 
>>>> I don't exactly disagree, but my understanding is that the work to do such a thing is nearly equivalent to having thread sanitizer on all the time. But maybe there's a simpler model that we could still turn on in debug builds. Can you file a bug report requesting this now that bugs.swift.org is back up?
>>> 
>>> Something like ConcurrentModificationException ought to be cheaper than the thread sanitizer. The thread sanitizer works hard to detect every concurrency error. ConcurrentModificationException typically does something simple and cheap that catches errors sometimes but makes no attempt to be exhaustive.
>>> 
>>> Objective-C's fast enumeration protocol includes a mechanism like this. The collection can have a simple mutation counter, and the enumerator captures the counter's value at the start and checks that the value is unchanged as the enumeration proceeds.
>> 
>> Does ObjC synchronize the mutation counter?  My understanding is that that counter was used to detect mutation while iteration on a single thread, not across threads.
> 
> The mutation counter is not synchronized; this is safe for correct code. An un-synchronized counter can still sometimes catch mutations from other threads.
> 
> 
> -- 
> Greg Parker    
> gparker at apple.com     Runtime Wrangler
> 
> 
> 
> 
> 
> 
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20180108/c2944b8c/attachment.html>