Hacker News Reader

Comment by asveikau | Hacker News Reader

> This post talks about the use of OS low level atomic functions

This is a pet peeve of mine, to call that an "OS" feature. In all recent CPUs I know of, atomic ops are not a privileged operation, and there is absolutely nothing for the operating system to manage in a traditional sense. You don't trap into the kernel and have it compare-and-swap, you just, um, compare and swap.

Maybe your OS provides a convenient C API, but it is not "OS" functionality. It's just instructions on your CPU. You could just as well write them inline. In many common uses, that's what ends up happening - the atomic ops are put inline with the rest of your code.

View on HN

If your use of atomics consists entirely of calling functions provided in a library as part of the OS, what's wrong with calling them "OS atomic functions"? That is what they are. The fact that you can accomplish the "atomic" part without the "OS functions" part doesn't change the fact that, as written, the article discusses the "OS functions" part.

Well, it looks like Apple named this particular API "OS atomics", a name which makes me cringe a bit.

But, a few points:

1. There is historically a distinction between "operating system" and "shared library shipping with the operating system". I think I am losing this battle though.

2. On a number of platforms (not sure if Apple's "OS atomics" concept counts here), the atomic wrappers are not even functions in a shared library. They may be declared inline in a header file. Or they may be compiler intrinsics, where the compiler doesn't generate any function call in any circumstances. Is that an "OS function"? Not really.

In either case #1 or case #2, I think "OS atomics" is a dumb name. We are really talking about CPU features, not OS features. If it doesn't generate a trap into kernel mode that doesn't very much sound like the OS doing the work.

Calling it "the OS" sounds more like a fundamental misunderstanding of dynamic linking and what it is. I hear so many variants of this core misunderstanding all over the place. Thinking that spinlocks need kernel help is one such manifestation.

#1 sounds like a pretty minority viewpoint. OSes these days are a lot more than just the kernel and things that call into the kernel. If you do a fresh install of the OS then I think what you find on the disk afterwards can all be reasonably referred to as "the OS."

#2 does not apply here. This particular API isn't implemented inline, or with compiler intrinsics, or assembly. They're actual calls.

If you're talking about the general concept of atomics, then I agree that "OS atomics" is a dumb name. But we're not talking about that. We're talking about a specific API that happens to implement that general concept. That specific API is part of the OS.

Fair. I just didn't know how to rephrase that small sentence without unfolding into the two paragraphs you just wrote.

How would you rephrase that? Just "low level atomic", "atomic"?

If atomic operations were compatible across processor "families" then you'd have "the family atomics." (Obscure Dune reference.)

That was worth 10 upvotes, good sir. Sadly, I can only provide one.

hardware-provided atomic?

At least for ARM on Linux, the kernel does provide cmpxchg in the VDSO, but I think that is for support on older ARM architectures. IIRC, the ARMv7 does not need to use the kernel helpers.

https://www.kernel.org/doc/Documentation/arm/kernel_user_hel...

Yes, pre-ARMv6 does not have the load-link/store-conditional instructions.

The Linux kernel hack for that is actually kind of awesome. Notably, it's not a syscall and you don't enter the kernel to do them. Since pre-ARMv6 is always single core, it simply becomes a matter of detecting you are in the middle of an atomic op at interrupt time, and patching the result. This means the atomic op has to happen at a well-known (kernel-provided) address. Details here: http://lwn.net/Articles/314561/

I'm also aware of some older systems that needed kernel intervention for atomic ops. But on x86, ARMv6+, even no longer relevant arches like SPARC, POWER, ... this is not the case. It really is rare that the kernel needs to do this job these days.

Edit: ARMv6, not ARMv7, per the link I provided...

Reply on news.ycombinator.com