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@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: johanneswe...@apple.com [mailto:johanneswe...@apple.com] > Sent: 17 January 2017 18:37 > To: Dale Myers <dal...@microsoft.com> > Cc: swift-users@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-users >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
