"The C standard will eventually support concurrency (they are working on it), and it will almost inevitably be a horrible pile of stinking sh*t, and we'll continue to use the gcc inline asms instead, but then the gcc people will ignore our complaints when they break the compiler, and say that we should use the stinking pile-of-sh*t ones that are built in.
"No, I haven't seen the drafts, and maybe I'm overly pessimistic, but I'm pretty sure that this is an area where (a) the kernel needs more support than most normal pthread-like models and (b) any design-by-committee thing simply won't be very good, because they'll have to try to make everybody happy. Oh well."
I really think this
I really think this complaint is unjustified -- at least the C++0x standards proposals for atomic operations and fences look entirely sane to me:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html
If Linus dislikes the decision of coupling "fences" with some operation on a variable, then he should just have a second look at abominations such as "smb_mb__after_atomic_dec" that exist only to optimize out fences on architectures where they are implicit to atomics -- to me the other way around feels much saner.
Now technically speaking the C++ committee is right that there *must* be a subsequent memory operation, so you can in theory always attach the fence to this load/store operation that finalizes some memory access -- whether it is always easy to refactor the code such that the barrier is moved from its present location to the finalizing load/store is a different question, but I would tend to say that it makes the code more robust as the synchronizing sequence point becomes better thought out and visible.
Just my 2 cts
C++?
What relevance does C++0x have to 200 megabytes of C code?
Relevance
According to an interview with Stroustrup, the concurrency support in the next C standard will be based on the support added to C++.
Limbo
Imagine if we would switch language from C to something else?
Limbo?
* http://en.wikipedia.org/wiki/Limbo_(programming_language)
Is it good?
not for writing kernels.
not for writing kernels.
What about XL macros ?
What about XL macros ?
Microsoft Singularity
Microsoft is writing Singularity in ProtoLisp, C#, and Sing#.
* http://en.wikipedia.org/wiki/Singularity_(operating_system)
Re: Microsoft Singularity
and C++/asm for what essentially is a microkernel.
Uh, what?
Sounds to me like mr. Torvalds seriously needs to get with the program. Or write his own damn operating system implementation language, with blackjack & hookers etc...
I support that notion but
I support that notion but lets skip the operating system and go directly to blackjack and hookers.
In fact, forget the
In fact, forget the blackjack.
I seem to remember Linus
I seem to remember Linus saying that he names all his software after himself, I await the lifestyle change that will bring about the Hooker programming language with great anticipation.
he doesn't seem to like gcc either
He doesn't seem to like gcc compiler very much, either.
Not quite true
Rather, he gets annoyed with the GCC developers, because they have different goals than his. He wants a good language to implement the kernel in, with compiler semantics that are sane for what he's trying to achieve. The GCC folks want to aggressively optimize applications, potentially taking whatever liberties the C standard lets them take.
One place where things get muddy is that GCC doesn't take every liberty offered by the C standard, but rather conservatively handles *some* constructs. But which constructs it does this for is up for debate.
One area where GCC has gotten more aggressive over the years involves code motion and transformation of memory accesses. When the compiler moves memory accesses around barriers and control constructs, it's next to impossible intuit what a given chunk of C code will do when compiled as part of the kernel. Such transformations may be invisible to a userland app, but are murder to the kernel, particularly in device drivers or in an SMP context. As the compiler gets "smarter", it does this more often, and it "knows" (or thinks it knows) about more constructs that it could move things past. (e.g. moving a memory reference past an asm() block, because it's "sure" no reference in the asm() block aliases it.)
So anyway, I don't think it's that he specifically dislikes GCC so much as it is that the C language as defined today doesn't give him what he wants—nor is it moving in a direction he likes—and so any compiler that aggressively implements the standard will aggravate him. I don't think he's alone in this, and I don't think it's specific to GCC. He'll complain about GCC because that's the compiler he's using. He'll complain about the GCC developers because they're not serving his goals. But frankly, he'd be similarly upset with any compiler that didn't cater to the kernel's needs. I seem to recall that this disconnect between what the kernel wants and what the compiler provides was part of the rationale for pcc reemerging in the BSD world.
--
Program Intellivision and play Space Patrol!
about compiler reordering
> (e.g. moving a memory reference past an asm() block, because it's "sure" no reference in the asm() block aliases it.)
If you rely on gcc *not* moving a memory reference past such a block, then your program is buggy. There is a reason gcc provides the "volatile" qualifier (and it's nicely documented BTW).
gcc provides very fine-grained mechanisms that allows the programmer to specify such dependencies, magically expecting gcc to "guess" what the programmer meant expects a bit too much -- and foregoing useful optimizations just because some programmers are too lazy to provide the required information to the compiler (or too dumb to understand the memory model) just punishes OTHER programmers who write proper code with an underperforming compiler.
Disclaimer: I'm not a gcc developer, but I happen to like gcc and see the development as a GOOD thing.
Which "volatile?"
Which volatile keyword are you referring to? The volatile storage class, or __asm__ __volatile__, or...?
Here are some interesting snippets of the discussion. (Toggle open the quoted text for fuller context.) It was that second exchange I was referring to when I made my parenthetical comment.
--
Program Intellivision and play Space Patrol!
The storage class. The
The storage class. The __volatile__ asm qualifier only guarantees the code is emitted at all and will not be removed due to CSE.
Of course it is preferrable to using the input/output constraints, but sometimes this does not work. You can always avoid the problem by specifying a "memory" clobber, but this may be sub-optimal to just forcing individual variables from/to memory.
Volatile not enough
Declaring a variable volatile is not enough to keep it from being moved. All that volatile means is that the compiler can't optimize away any reference to that variable by assuming it knows what the value is: the value must be explicitly fetched every time. That does NOT mean the compiler can't move the reference around in the code if the optimizer wants to (and it doesn't break any ordering rules in the C standard).
In fact I just ran into a bug like this in my userspace code last week: a long-standing fast userspace mutex implementation we had been using, unchanged and forgotten about, since Linux 2.4 days (before POSIX mutexes) had an unlock that simply set a volatile int to 0. With GCC 3.x and below that worked 100% of the time. I upgraded to GCC 4.2.4 and (after a lot of poking and reading assembly) discovered that the compiler had optimized some of my code that was supposed to be protected by the mutex, outside of the protected area (after the assignment to 0). I introduced a true memory barrier and voila! No more bug.
You got lucky with GCC 3.x
Even if that assignment to 0 got scheduled after your code, if it was near enough to the code, the CPU may reorder it on you. To be truly correct, you need a true memory barrier that prevents both the compiler and the CPU from reordering the sequence. It sounds like that's what you've added.
--
Program Intellivision and play Space Patrol!
C is a high level cross
C is a high level cross platform assembler for writing UNIX in, adding syntactical sugar on top seems a ridiculous idea as it undermines the point of C. They will end up inlining assembler everywhere to side step this issue which does no one any good.
Yes and no
C is "high" level compared to assembler but it doesn't mean that it couldn't be implemented. I wonder how many remember PL/I - add option task to proc and you had a parallel execution. And it was real parallel, not just a thread. Of course - some small problems as the proc had to be re-entrant and even the compiler couldn't always check that. Now - after seeing what a mess C++ (and C# - even worse) came, I don't have very high confidence that it will be that simple - they syntax probably will be much over designed, bloated, etc - KISS is not the first thing what we see coming out today.
It goes without saying it
It goes without saying it could be implemented, and apparently it will, but that is not what I'm getting at. OSes are written in C in order to get at the hardware in a portable way, with assembler gubbings to do the non-portable stuff.
I don't think anyone wrote an OS in PL/I as it was a much higher level language than C is supposed to be.