Hacker News Reader

Comment by ChrisMarshallNY | Hacker News Reader

This is cool. It does address (partly) some of the issues with Swift threading.

That said, I’m not a systems programmer, and basic threads, like those provided by the standard “blunt instrument” approach of standard Swift, will pretty much always give me what I need.

Using threads -especially low-level threads- can lead to a real education in debugging. I only use them when necessary.

View on HN

> It does address (partly) some of the issues with Swift threading.

FWIW, this is among the first of quite a few concurrency improvements coming to Swift in the near future. Swift 6 is expected to include a real concurrency model, likely based on some combination of async/await and an actor model.

The devs have been actively implementing a prototype [0], and the core team is expected to release a design document/proposal soon [1] [2].

[0]: https://github.com/apple/swift/pulls?q=concurrency [1]: https://forums.swift.org/t/rethinking-async/37984/30 [2]: https://forums.swift.org/t/rethinking-async/37984/51

> Using threads -especially low-level threads- can lead to a real education in debugging.

Oh yeah it can. I'm still scarred by an error that took me a month to solve: I was self-teaching pthreads and kept getting an access violation with a stack trace starting at 0x0.

The only bug that ever beat me in my two decades coding was in a custom lock free data structure using an early version of c++11. I spent a month on it, including writing custom visualization and logging tools, but I never found the issue that caused a crash once every few hundred billion operations.

Later I saw some suspicious compiler bug fixes around compare and swap, and I still wonder if that was maybe it.

1 in every hundred billion... is that low enough odds to be cosmic rays?

A hundred billion operations is spinning on a loop for a couple minutes, so not really.

It took about ten minutes at full system utilization on all cores, running the "torture test" in a loop in each thread.

For a cosmic ray bit-flip, or to perform a hundred billion operations?

One hundred billion operations. The machine didn't have ECC memory, so a bit flip is a possible explanation. I should have checked if it was reproducible with ECC.

I still think a logic bug or compiler bug was at fault though.

Obligatory sometimes, just sometimes, it is the compiler.

I read that some lock free libraries needed to be updated when Apple released it's first dual core ARM processors. Something about ARM's read or write ordering guarantees are looser than Intels.

Me I'd rather roll my own cryto than try and write my own lock free data structure.

Fun fact: Apple's recent processors have a mode where they emulate stricter ordering guarantees (for Rosetta, of course).

That reminds me I think I saw some blurb in an MCU data sheet that mentioned the processor can do out of order memory accesses which if you're an embedded guy tends to freak you out. However the chip designers disabled that for peripheral memory accesses.

Which is very nice of them.

Yes, this is something where different CPU architectures do it differently, even between ARMv7 and ARMv8 etc. There's a great presentation on the differences here:

https://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-20... https://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-20...

He goes into the details of ARM vs Intel etc in the middle of part 2, but really part 1 is well worth a watch.

It does, but like the article says this is generally not something you want to be touching. The number of users of this API is likely to be very small, for the rest Grand Central Dispatch is what you should probably reach for.

This is true, but every non-trivial app requires the equivalent of `std::atomic_flag` and `std::atomic<int>` at some point...

Not really. If you don’t mind having the absolute best performance, normal queues and locks work just fine.

Reply on news.ycombinator.com