Re: [PATCH 11/18] seqcount: Introduce raw_write_seqcount_barrier()

From: Paul E. McKenney
Date: Thu Jun 18 2015 - 13:52:10 EST


On Thu, Jun 18, 2015 at 01:10:22PM -0400, Steven Rostedt wrote:
> On Thu, 18 Jun 2015 09:54:07 -0700
> "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
>
> > Yep, I have to frequently remind them that most projects need to support
> > old compilers. And I did point out that the commentary at the end
> > of that document would not encourage adoption of C11. They of course
> > felt this was unfair of me, so I have to thank you both for proving the
> > correctness of my reply to them. Although you guys didn't use quite as
> > many swear words as I would have expected. ;-)
>
> I could add a few more if you would like ;-)

I bet! ;-)

> What's their issue? Is there some kind of benchmark war going on
> between different compilers? Where they want want to prove they can
> produce the absolute fastest code possible, but only use single
> threaded apps and screw those that must support multi-threaded
> applications.
>
> My phone and my camera have multicore systems. Single threaded is not
> the way of the future. Which ever compiler makes it easier to write
> multi-threaded applications is going to win, regardless of how well a
> compiler can claim they optimize code the best for a single threaded
> app.

Their viewpoint is that they have produced syntax for marking shared
variables and also for marking accesses to shared variables, and that for
code that is not using those markings, anything goes. They need frequent
reminders of the need to accommodate pre-existing code, and usually don't
take such reminders very well. Ditto for projects such as the Linux
kernel to support pre-C11 compilers, and that need production-quality
compiler support.

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/