{"id":24198,"date":"2019-02-05T16:29:39","date_gmt":"2019-02-05T21:29:39","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=24198"},"modified":"2019-02-26T15:49:03","modified_gmt":"2019-02-26T20:49:03","slug":"swift-5-exclusivity-enforcement","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2019\/02\/05\/swift-5-exclusivity-enforcement\/","title":{"rendered":"Swift 5 Exclusivity Enforcement"},"content":{"rendered":"<p><a href=\"https:\/\/swift.org\/blog\/swift-5-exclusivity\/\">Andrew Trick<\/a>:<\/p>\n<blockquote cite=\"https:\/\/swift.org\/blog\/swift-5-exclusivity\/\"><p>The Swift 5 release enables runtime checking of &ldquo;Exclusive Access to Memory&rdquo; by default in Release builds, further enhancing Swift&rsquo;s capabilities as a safe language. In Swift 4, these runtime checks were only enabled in Debug builds.<\/p><p>[&#8230;]<\/p><p>In essence, a variable cannot be accessed via a different\nname for the duration in which the same variable is being modified as an <code>inout<\/code> argument or as <code>self<\/code> within a <code>mutating<\/code> method.<\/p><p>[&#8230;]<\/p><p>The overhead of the memory access checks could affect the performance of the Release binary. The impact should be small in most cases; if you see a measurable performance regression, please file a bug so we know what we need to improve. As a general guideline, avoid performing class property access within the most performance critical loops, particularly on different objects in each loop iteration. If that isn&rsquo;t possible, making the class properties <code>private<\/code> or <code>internal<\/code> can help the compiler prove that no other code accesses the same property inside the loop.<\/p><p>[&#8230;]<\/p><p>The combination of compile-time and run-time exclusivity checks described above are necessary to enforce Swift&rsquo;s <a href=\"https:\/\/docs.swift.org\/swift-book\/LanguageGuide\/MemorySafety.html\">memory safety<\/a>. Fully enforcing those rules, rather than placing the burden on programmers to follow the rules, helps in at least five ways[&#8230;]<\/p><\/blockquote>\n\n<p id=\"swift-5-exclusivity-enforcement-update-2019-02-26\">Update (2019-02-26): <a href=\"http:\/\/www.russbishop.net\/the-law\">Russ Bishop<\/a>:<\/p>\n<blockquote cite=\"http:\/\/www.russbishop.net\/the-law\"><p>This has some interesting interactions with atomics, especially when running under the <a href=\"https:\/\/clang.llvm.org\/docs\/ThreadSanitizer.html\">Thread Sanitizer (TSAN)<\/a>. If you&rsquo;ve ever seen a TSAN report on some simple Swift code that looks <em>obviously<\/em> correct then you&rsquo;re probably running into this issue[&#8230;]<\/p><p>[&#8230;]<\/p><p>The problem lies in the <a href=\"https:\/\/github.com\/apple\/swift-evolution\/blob\/master\/proposals\/0176-enforce-exclusive-access-to-memory.md\">Law Of Exclusivity<\/a>. The ampersand operator in Swift is not the same as C&rsquo;s <em>address of<\/em> operator. It is the inout operator.<\/p><p>[&#8230;]<\/p><p>The takeway is this: Under the Swift memory model the <code>UnsafeLock<\/code> shown above is illegal. The correct strategy is to allocate storage for the lock yourself[&#8230;]<\/p><\/blockquote>\n<p>He does this using an <code>UnsafeMutablePointer<\/code>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Andrew Trick: The Swift 5 release enables runtime checking of &ldquo;Exclusive Access to Memory&rdquo; by default in Release builds, further enhancing Swift&rsquo;s capabilities as a safe language. In Swift 4, these runtime checks were only enabled in Debug builds.[&#8230;]In essence, a variable cannot be accessed via a different name for the duration in which the [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"2019-02-05T21:29:42Z","apple_news_api_id":"e3b0df3c-df02-4af9-844b-8bee41ab2b42","apple_news_api_modified_at":"2019-02-26T20:49:07Z","apple_news_api_revision":"AAAAAAAAAAAAAAAAAAAAAA==","apple_news_api_share_url":"https:\/\/apple.news\/A47DfPN8CSvmES4vuQasrQg","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[4],"tags":[800,46,71,901],"class_list":["post-24198","post","type-post","status-publish","format-standard","hentry","category-programming-category","tag-concurrency","tag-languagedesign","tag-programming","tag-swift-programming-language"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/24198","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=24198"}],"version-history":[{"count":2,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/24198\/revisions"}],"predecessor-version":[{"id":24417,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/24198\/revisions\/24417"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=24198"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=24198"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=24198"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}