[swift-users] Bool type and reading and writing operation atomicity

[Zhao Xin]

You can use the GCD semaphore.
https://developer.apple.com/reference/dispatch/dispatchsemaphore

Or it is always better to consider of using queues if you can.

https://developer.apple.com/library/content/documentation/General/Conceptual/ConcurrencyProgrammingGuide/ThreadMigration/ThreadMigration.html#//apple_ref/doc/uid/TP40008091-CH105-SW1

Zhaoxin

On Wed, Jan 18, 2017 at 5:53 PM, Dale Myers via swift-users <
swift-users at swift.org> wrote:

> Compiler optimisations are something I completely ignored in my reasoning,
> which as has been pointed out was clearly a mistake.
>
> We will switch to using something that provides atomic operations.
>
> Thanks!
>
> -----Original Message-----
> From: johannesweiss at apple.com [mailto:johannesweiss at apple.com]
> Sent: 17 January 2017 18:37
> To: Dale Myers <dalemy at microsoft.com>
> Cc: swift-users at swift.org
> Subject: Re: [swift-users] Bool type and reading and writing operation
> atomicity
>
> Hi,
>
> > Put simply, are reading and writing to Bools both atomic operations in
> Swift (3)?
>
> you don't get a guarantee for that as Swift at the moment lacks both, a
> memory and a concurrency model.
>
>
> > Obviously, something reading and then assigning assuming the value
> doesn't change between is not correct, but would something like the
> following be fine:
> >
> >    var myBool = false
> >
> >    // Thread 1
> >    while true {
> >        if randomEvent() {
> >            myBool = true
> >        }
> >    }
> >
> >    // Thread 2
> >    while true {
> >        if myBool {
> >            print("Was set to true")
> >        } else {
> >            print("Not set")
> >        }
> >    }
> >
> >
> > I understand that in thread 2, the value of myBool can change between
> the check and the print statements, but that's fine. What I want to confirm
> for my team is that `myBool` can never be in some weird "third" state?
>
> As far as I know, you don't get a guarantee for that. But worse (and just
> like in C/C++/...) you most importantly don't get the guarantee that Thread
> 2 will ever see the change of Thread 1. The compiler could also optimise
> the code in Thread 2 to
>
> while true {
>    // if false {
>    //     print("Was set to true")
>    // } else {
>           print("Not set")
>    // }
> }
>
> ie. the compiler could 'prove' that `myBool` is never written (legally)
> and therefore delete all the code that assumes myBool != false.
>
> I'm not saying the compiler is doing this today but AFAIK it could do so
> if it wanted.
>
>
> > From what I can tell, behind the scenes, Bool uses a Builtin.Int1 for
> storage. I can't find the definition for this type anywhere so I can't
> check what it is really doing. My assumption is that it uses something like
> a C++ unsigned char behind the scenes, which would be fine with the above
> code on x86 and ARM as far as I'm aware.
>
> In C/C++ you'd need the new _Atomic variables to get that guarantee.
>
>
> > [...]
>
> Again, I'm not saying the compiler does do that but AFAIK it could do so
> legally. But one of the compiler people can answer these questions much
> better than I can.
>
> Cheers,
>   Johannes
> _______________________________________________
> 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/20170120/9ba906ce/attachment.html>