Hacker News Reader

Comment by stcredzero | Hacker News Reader

Swift doesn't seem to have anything to do with the parallel language at swift-lang.org.

Whoops. Should've corrected that when I copied the comment over.

In any case, reference counting is disastrous for the parallelism story. GC thread coming along and causing an additional cache miss is way better than having to do atomic operations on reference counts all the time.

Why are atomic reference counts necessary? You wouldn't generally need them with an Erlang-like Actor model or for special concurrency primitives like Go channels. (That is to say, you'd only need them in the special mechanisms.)

View on HN

I'm not sure you can be Objective-C compatible without a shared heap. If you have a shared heap, you need atomic reference counting.

No. If you take the attitude that you're only covered if you use the concurrency primitives correctly, then you don't need atomic reference counting for everything. Basically, the programmer can use CSP to ensure that only one thread is messing around with any given section of the heap at a time, and the language implementers could say you're SOL if you do otherwise. (That probably isn't the Apple way, though.)

Swift uses the Obj-C runtime and interoperates with Obj-C code. Those languages assume a shared heap. If Swift modules didn't perform atomic reference counts, that would quite likely break Obj-C code operating on the same heap.

You'd break a ton of Cocoa APIs too.

It should still be possible to have the compiler interpose mechanisms between everything else and the Swift code, such that your Swift code has a section of heap all to itself. By the time you're done with that, you're halfway to having implemented your own Erlang on the Obj-C runtime. That might be worth doing, though.

Swift is based on the ObjC runtime, which means you have a shared heal and the possibility of multiple threads adjusting counts at the same time.

Yes, but with something CSP-derived, you could design a runtime where you're covered if you use the concurrency facilities correctly, and you're SOL if you don't. Then only the concurrency primitives need atomic refcounts.

Possibly, but it's very handy to let immutable data be read by any thread that wants to. If, however, it's very slightly mutable due to a ref counter, you have to atomically manage the counter, even for what should be free immutable reference.

I'm managing something like this in Go. There are no refcounts, but everything is very much mutable. I'm basically arranging for a span of time where I know nothing unprotected by a channel is going to be mutated, then I simply let every thread in the app that cares to read data from every part of the heap, but only during this span of time. The same technique could be applied to a ref counted app. (It would probably work best for games that have a tick.)

Interesting.

I still think it would be hard to apply to a ref counter app, since you'd need to keep track of change in ref count for later cleanup (thread-local per object maybe? sounds inefficient), but I now will admit that it sounds possible.

Reply on news.ycombinator.com