>post c99 additions being pointless
Atomics are necessary nowadays though.
Atomics are necessary nowadays though.
Not that I'd want it, I like complex type systems, but I see it as philosophically consistent with C.
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...
> We explicitly do not address the less frequently used environments in which multiple concurrent threads communicate communicate primarily through message passing, such as C programs communicating only through the MPI[34] library, or Erlang[11] or Concurrent ML[28] programs.
Heh, there's your answer. CSP FTW!
That's something pthreads do and CSP doesn't.
> you need a memory model with compiler support. Even if you exclusively use mutexes.
If you use CSP you can effectively eliminate shared memory in user space and you don't have to handle this with the compiler. Then you can say "here's a way to communicate between processes in user space, the runtime/kernel handles the shit underneath. If you want to do it some other way we can't guarantee it'll work."
https://en.wikipedia.org/wiki/Communicating_sequential_proce...
> but if you eliminate shared memory and have the kernel copy data between threads, you're leaving a ton of performance on the table.
If that's your bottleneck then you've either already solved every other class of performance issue with your program or you're working in a fantasy environment-- you're probably not hacking on FFmpeg right now. 90% of performance is I/O bound, whether it be the disk, the network or whatever. You can easily ascertain the correctness of a CSP system, because it's just message passing and inherently synchronous. Not so much with shared memory. It's a tradeoff. Unix pipes are also pretty goddamn fast, like, this is an issue people have spent time squeezing as much performance as possible out of. Google uses Go for all of their important backend shit. The entire internet is a giant message passing system.
funny you say that, because to take advantage of the monstrous bandwidth offered by modern ethernet, OS bypass with the card DMAing directly in your process cache is a must. That reintroduces all the "fun" shared memory ordering issues, except trickier (you are talking with a PCI device, not just another core) and buggier.
Re disk, I'm sure someone will revive optane at some point, and we will be back with memory model issues in our disk I/O path.
The reality is that a programming language that claims to be usable for system programming must be able to deal with shared memory and provide a concurrent memory model.
Architecture problem. Do your programs normally saturate a 40 gig network pipe?
> The reality is that a programming language that claims to be usable for system programming must be able to deal with shared memory and provide a concurrent memory model.
You can boot up a Plan 9 kernel and tell me if it works or not. Like, this is not a high bar, but you keep treating it like it is because it's based on the assumption that all compilers are broken with the set of all compilers being GCC.
yes
And of course any sufficiently complicated message passing program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of shared memory and coherency[1].
[1] Yes, the reverse is also true.
And, FWIW, in a lot of high-performance code, the overhead of a function call may be too high for an atomic operation.
That's an assumption that you're treating as though it somehow informs reality. I gave you an example of atomics being handled by a library, and the man page points to where in the source code it's defined.
> so you'd need to know how Plan 9's compiler/language specifies atomics.
It doesn't, as far as I can tell. Kencc is a very "dumb" compiler that does little magic nor does it extend the language beyond the standard C that the Bell Labs guys were used to. For whatever reasons, they found it expedient to write new libraries instead of changing the language itself. They did occasionally write compilers for new languages when they had wacky ideas that would be difficult to accomodate, like Newsqueak and Alef. In Alef's case they actually did accomodate some of it, which is how Plan 9 got libthread.
Of course no doubt that (hopefully) C compilers used for compiling plan 9 things won't break it, but...that's then talking about plan9-C, not C99, at which point you're necessarily already in the bucket of "this library relies on extra guarantees that plan9 C makes, instead of it just being a regular C99 library".
> > so you'd need to know how Plan 9's compiler/language specifies atomics.
> It doesn't, as far as I can tell. Kencc is a very "dumb" compiler
...So it effectively quietly makes a bunch of quiet guarantees that C99 doesn't, on account of not making certain valid optimizations. Even if not explicit, that's still semantics outside of those C99 specifies, that code may be relying on.
Fact of the matter is, you cannot make a full atomics library that will necessarily work correctly on C99. As a simple example I came up with on the spot:
static int foo;
int main() {
some_preparation();
foo = 2;
fence_probably();
do_thing(&foo);
}
But, if atomics exist, `do_thing` could do a relaxed store of its given foo address to a global, and another thread could then do a relaxed load of that and dereference that to get foo's value. And if the compiler decides to reorder the store to `foo` to after the fence (as a C99 compiler can), the program now has a data race that it otherwise would not.
(hell, a C99 compiler could even insert `int tmp = something; something = 123; something = tmp;` for any variable or global or field `int something`, in any place in the code (as long as `something` is known to be mutable), which'd break basically every multithreaded thing; this effectively one of the things the "Threads Cannot Be Implemented As a Library" paper mentions)
You use the Plan 9 compiler to compile Plan 9 programs. Attempts at trying to get GCC to compile Plan 9 programs correctly have been mixed.
> So it effectively quietly makes a bunch of quiet guarantees that C99 doesn't
Yeah. It's not a C99 compiler.
> Even if not explicit, that's still semantics outside of those C99 specifies, that code may be relying on.
Yeah. They're not C99 programs.
> Fact of the matter is, you cannot make a full atomics library that will necessarily work correctly on C99.
Sounds like C99's problem.
At least to me, section 4 seems to imply that the "assumption" is a bit more than just that. For example:
> We know of at least four optimizing compilers (three of them production compilers) that performed this transformation at some point during their lifetime; sometimes at least partially reversing the decision when the implications on multi-threaded code became known.
i.e., there are real-life instances of the lack of compiler/language support leading to miscompilations. Yes, that example is talking about threads, but I think a similar argument should apply to atomics.
> I gave you an example of atomics being handled by a library
The thing is that nothing in that man page indicated to me that that library wouldn't be subject to problems similar to that described in Boehm's paper; e.g., for all I know that library is the Plan 9 moral equivalent of pthreads and is subject to similar problems pthreads is when a non-thread-aware optimizing compiler is used.
> Kencc is a very "dumb" compiler that does little magic
This could (partially?) address things though. If Plan 9 always uses that compiler and if there's no interest in implementing the optimizations Boehm describes then that would obviate 2 of the 3 correctness issues Boehm describes (though that would also imply that Plan 9 uses its own dialect of C with its own set(s) of guarantees, both explicit and implied). The only thing I'm uncertain about is to what extent hardware reordering would be relevant; I thought I remember reading about that making things interesting, but I don't remember off the top of my head to what extent.
To quote Rob Pike,
"Early 1990s: Alef (Phil Winterbottom) grafted the concurrency and communications model of Newsqueak onto a more traditional compiled C-like language.
Problem: with C's memory model in a concurrent world, hard to know when to free items.
All the other languages in this talk are garbage-collected, which is essential to easy concurrent programming."
http://go-lang.cat-v.org/talks/slides/emerging-languages-cam...
which is precisely why they can get away with a library seemingly without having to specify or coordinate anything with the compiler.