Remix.run Logo
▲ 201984 6 hours ago

>post c99 additions being pointless

Atomics are necessary nowadays though.

▲3836293648 5 hours ago | parent [-]

As a part of the language? Are they really? You can do it all with library functions that just take regular int* (and so on).

Not that I'd want it, I like complex type systems, but I see it as philosophically consistent with C.

▲aw1621107 5 hours ago | parent | next [-]

> You can do it all with library functions that just take regular int* (and so on).

It's not just about atomics, but you might still find Hans Boehm's 2005 paper "Threads Cannot Be Implemented As a Library" [0] interesting. It describes (among other things) correctness and performance issues that can arise if the compiler and/or language don't know about thread/atomic semantics.

[0]: https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/o...

▲Joker_vD 3 hours ago | parent [-]

Yeah, it's all fun and games until you realize that you compiler may invent writes in order to eliminate a branch. Which is rather nonsensical, when you stop to think about it — surely an additional store to global can't be faster than a mispredicted branch?

▲homosapien97 2 hours ago | parent | next [-]

Branch mispredictions on deep machines can be devastating, whereas a store can hit in your L1. Storing can definitely be faster than a mispredicted branch if you think you'll hit in your L1/L2

▲adgjlsfhk1 2 hours ago | parent | prev [-]

store to a global is typically 0 cycles (although subsequent reads may be slowed down)

▲jcranmer 5 hours ago | parent | prev | next [-]

Compilers have, for several decades now, stopped viewing optimization in terms of optimizing the instructions of a function and instead viewed it as preserving the semantics under some machine model. Consequently, it's rather important to actually nail down some of the object model semantics to be able to do things like understand which loads and stores actually need to be preserved, and you can't really do that with just library functions.

And, FWIW, in a lot of high-performance code, the overhead of a function call may be too high for an atomic operation.

▲publicmail 5 hours ago | parent | prev | next [-]

A library function written in what? Atomics also come along with memory ordering which isn’t otherwise expressible in the language, as in, there was no standard way to do a “load acquire” before, for example.

▲ an hour ago | parent [-]
[deleted]
▲dokyun an hour ago | parent | prev [-]

Funny this is getting downvoted cause it's literally what Plan 9 C does.

https://man.cat-v.org/plan_9/2/atom

▲aw1621107 3 minutes ago | parent [-]

I don't think that man page on its own is sufficient to draw that particular conclusion. You need compiler/language support to ensure atomics are handled properly, so you'd need to know how Plan 9's compiler/language specifies atomics.