[swift-users] Is this really a race condition?

[Zhao Xin]

I am sorry if this bothers you. I just put the original code in Xcode and
it works. Anyone knows why this works in Xcode or in macOS? I thought it
should show the same warnings as Linux.

Zhaoxin

On Fri, Mar 3, 2017 at 2:51 AM, Edward Connell via swift-users <
swift-users at swift.org> wrote:

> Hi Guillaume,
> There is still a race condition report, but I think maybe we are almost
> there. I had to modify your example because it didn't quite build, and a
> loop to do it twice since it randomly complains if you only do it once.
> Btw, this is on Linux.
> The warning is triggered when deinitialize is called. It wasn't in your
> example, but it seems that it is required since the Elements are not a
> trivial type like Int.
>
> Thanks, Ed
>
> for _ in 0..<2 {
> let count = 1000
> let items = UnsafeMutablePointer<[UInt8]?>.allocate(capacity: count)
> items.initialize(to: nil, count: count)
>
> DispatchQueue.concurrentPerform(iterations: count) {
> items[$0] = [UInt8](repeating: 7, count: 10)
> }
>
> items.deinitialize(count: count)
> items.deallocate(capacity: count)
> }
>
> ==================
> WARNING: ThreadSanitizer: data race (pid=24076)
>   Write of size 8 at 0x7d0c00005fa0 by main thread:
>     #0 free <null> (libtsan.so.0+0x000000025819)
>     #1 _TwXxOs31_ClosedRangeIndexRepresentation <null> (libswiftCore.so+
> 0x00000027e071)
>
>   Previous write of size 8 at 0x7d0c00005fa0 by thread T20:
>     #0 malloc <null> (libtsan.so.0+0x0000000254a3)
>     #1 swift_slowAlloc <null> (libswiftCore.so+0x0000002ee3e5)
>
>   Thread T20 (tid=24288, running) created by main thread at:
>     #0 pthread_create <null> (libtsan.so.0+0x000000027577)
>     #1 manager_workqueue_additem /home/buildnode/disk2/
> workspace/oss-swift-3.0-package-linux-ubuntu-16_04/
> swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815 (libdispatch.so+
> 0x00000007c6b1)
>
> SUMMARY: ThreadSanitizer: data race ??:0 __interceptor_free
> ==================
>
>
> ThreadSanitizer: reported 1 warnings
>
>
>
> On Wed, Mar 1, 2017 at 6:48 PM, Edward Connell <ewconnell at gmail.com>
> wrote:
>
>> Ahh! thank you. That makes sense.
>>
>> On Wed, Mar 1, 2017 at 3:29 PM, Guillaume Lessard <
>> glessard at tffenterprises.com> wrote:
>>
>>>
>>> > On Mar 1, 2017, at 3:21 PM, Edward Connell via swift-users <
>>> swift-users at swift.org> wrote:
>>> >
>>> > The thread sanitizer on Linux is reporting that I have race conditions
>>> in libswiftcore. I eliminated enough code down to this trivial example. Is
>>> there really a race condition here or are these bogus errors?
>>> >
>>> >       let count = 1000
>>> >       var items = [[UInt8]?](repeating: nil, count: count)
>>> >
>>> >       DispatchQueue.concurrentPerform(iterations: count) {
>>> >               items[$0] = [UInt8](repeating: 7, count: 10)
>>> >       }
>>> >
>>> > My real scenario is retrieving data asynchronously, so I just threw in
>>> a buffer assignment.
>>>
>>> The assignments to array elements are where the race lies.
>>>
>>> I don’t know about the libswiftcore part, but: assigning to a shared
>>> Array concurrently from multiple threads won't work, because of Array's
>>> copy-on-write behaviour. You could do
>>>
>>> let items = UnsafeMutablePointer<[UInt8]?>.allocate(capacity: 1)
>>> items.initialize(to: nil, count: count)
>>>
>>> DispatchQueue.concurrentPerform(iterations: count) {
>>>   items[$0].initialize([UInt8](repeating: 7, count: 10))
>>> }
>>>
>>> // you’ll be able to see here that they’re all initialized
>>>
>>> items.deallocate(capacity: count)
>>>
>>> Cheers,
>>> Guillaume Lessard
>>>
>>>
>>
>
> _______________________________________________
> 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/20170303/a550b342/attachment.html>