New 12Jan2017, updated 3Feb2017
In this note I will try to track what’s happening with Swift and concurrency. I already have mentioned Swift some (http://www.teigfam.net/oyvind/home/?s=Swift) and I won’t repeat here – only to say that there per se, at the moment, is no concurrency support in the language. Swift 3 users are supposed to use GCD (Grand Central Dispatch) – which also addresses parallel processing (multi-core).
Swift was designed and built by Apple under the leadership of Chris Lattner, the (co)creator of LLVM compiler infrastructure and Clang (that Stallman doesn’t seem to like: Re: clang vs free software) – and now also Swift.
In August 2016 Chris Lattner, in a note to swift-evolution, asked people to wait with concurrency until the discussions for future Swift 4 (What’re the Swift team’s thoughts on Go’s concurrency?). As a “language owner” he seems to be entitled to do that:
There are many folks interested in concurrency topics related to this, but we need to stay focused on finishing Swift 3 and then moving on to Swift 4 stage 1 goals. As that work is cresting, we’ll start discussions of concurrency, and may even be so bold as to start a new mailing list dedicated to the topic, since it is such a wide reaching topic.
Until we get to that point, please resist the urge to jump ahead 🙂
Aside: Chris Lattner left Apple for Tesla to become Vice President of Autopilot Software in January 2017 ([swift-evolution] Update on the Swift Project Lead, Macrumours: Swift and Xcode Head Chris Lattner Leaving Apple for Tesla This Month and phoronix: LLVM Founder, Swift Creator Chris Lattner Is Leaving Apple: Joins Tesla). (Aside 2: I hope he didn’t back out because he thought concurrency was too difficult?) Ted Kremenek, who up to now has been leading the Languages and Runtimes team at Apple will lead the Swift project from now on. Isn’t concurrency much about good abstractions for runtime scheduling? After a day or so a comment was added by Lattner on swift-evolution, see Daring Fireball: CHRIS LATTNER ON TED KREMENEK.
It’s going to be exciting to see how concurrency or multi-core added to a language in a revision four of it might look. It’s easy to think that it would be as an afterthought. Whether that is bad or good, then, remains to be seen. .
Concurrency issues with 3.0
Searching for concurrency in swift-evolution (or “thread-safe”) I get some hits. The language designers are certainly preoccupied with the issues. After all, there is concurrency through GCD. Here are some matters I found, showing that the issues are not under the carpet:
- “Makes it feasible to fix existing concurrency issues in Set and Dictionary indices” (in A New Model for Collections and Indices of April 2016). In the same: “The issue that we were previously unaware of is that this scheme is not thread-safe. When uniquely-referenced storage is being mutated in place, indices can be concurrently being incremented (on a different thread). This would be a read/write data race.”
- “The NSLock family of classes and protocols will likely be revisited as part of the general concurrency effort in the next release of Swift. Therefore we will keep the NS prefix” (in Drop NS Prefix in Swift Foundation of May 2016)