<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">You can use the GCD semaphore.  <a href="https://developer.apple.com/reference/dispatch/dispatchsemaphore">https://developer.apple.com/reference/dispatch/dispatchsemaphore</a></div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Or it is always better to consider of using queues if you can. </div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif"><a href="https://developer.apple.com/library/content/documentation/General/Conceptual/ConcurrencyProgrammingGuide/ThreadMigration/ThreadMigration.html#//apple_ref/doc/uid/TP40008091-CH105-SW1">https://developer.apple.com/library/content/documentation/General/Conceptual/ConcurrencyProgrammingGuide/ThreadMigration/ThreadMigration.html#//apple_ref/doc/uid/TP40008091-CH105-SW1</a><br></div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Zhaoxin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 18, 2017 at 5:53 PM, Dale Myers via swift-users <span dir="ltr">&lt;<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Compiler optimisations are something I completely ignored in my reasoning, which as has been pointed out was clearly a mistake.<br>
<br>
We will switch to using something that provides atomic operations.<br>
<br>
Thanks!<br>
<div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: <a href="mailto:johannesweiss@apple.com">johannesweiss@apple.com</a> [mailto:<a href="mailto:johannesweiss@apple.com">johannesweiss@apple.<wbr>com</a>]<br>
Sent: 17 January 2017 18:37<br>
To: Dale Myers &lt;<a href="mailto:dalemy@microsoft.com">dalemy@microsoft.com</a>&gt;<br>
Cc: <a href="mailto:swift-users@swift.org">swift-users@swift.org</a><br>
Subject: Re: [swift-users] Bool type and reading and writing operation atomicity<br>
<br>
Hi,<br>
<br>
&gt; Put simply, are reading and writing to Bools both atomic operations in Swift (3)?<br>
<br>
you don&#39;t get a guarantee for that as Swift at the moment lacks both, a memory and a concurrency model.<br>
<br>
<br>
&gt; Obviously, something reading and then assigning assuming the value doesn&#39;t change between is not correct, but would something like the following be fine:<br>
&gt;<br>
&gt;    var myBool = false<br>
&gt;<br>
&gt;    // Thread 1<br>
&gt;    while true {<br>
&gt;        if randomEvent() {<br>
&gt;            myBool = true<br>
&gt;        }<br>
&gt;    }<br>
&gt;<br>
&gt;    // Thread 2<br>
&gt;    while true {<br>
&gt;        if myBool {<br>
&gt;            print(&quot;Was set to true&quot;)<br>
&gt;        } else {<br>
&gt;            print(&quot;Not set&quot;)<br>
&gt;        }<br>
&gt;    }<br>
&gt;<br>
&gt;<br>
&gt; I understand that in thread 2, the value of myBool can change between the check and the print statements, but that&#39;s fine. What I want to confirm for my team is that `myBool` can never be in some weird &quot;third&quot; state?<br>
<br>
As far as I know, you don&#39;t get a guarantee for that. But worse (and just like in C/C++/...) you most importantly don&#39;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<br>
<br>
while true {<br>
   // if false {<br>
   //     print(&quot;Was set to true&quot;)<br>
   // } else {<br>
          print(&quot;Not set&quot;)<br>
   // }<br>
}<br>
<br>
ie. the compiler could &#39;prove&#39; that `myBool` is never written (legally) and therefore delete all the code that assumes myBool != false.<br>
<br>
I&#39;m not saying the compiler is doing this today but AFAIK it could do so if it wanted.<br>
<br>
<br>
&gt; From what I can tell, behind the scenes, Bool uses a Builtin.Int1 for storage. I can&#39;t find the definition for this type anywhere so I can&#39;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&#39;m aware.<br>
<br>
In C/C++ you&#39;d need the new _Atomic variables to get that guarantee.<br>
<br>
<br>
&gt; [...]<br>
<br>
Again, I&#39;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.<br>
<br>
Cheers,<br>
  Johannes<br>
______________________________<wbr>_________________<br>
swift-users mailing list<br>
<a href="mailto:swift-users@swift.org">swift-users@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-users</a><br>
</div></div></blockquote></div><br></div>