By: anon (anon.delete@this.anon.com), July 13, 2015 6:43 pm
Room: Moderated Discussions
EduardoS (no.delete@this.spam.com) on July 13, 2015 4:56 pm wrote:
> Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on July 13, 2015 4:36 pm wrote:
> > The point is, you can't. Ignoring the fact most people wouldn't understand the intricate details of
> > say the x86 memory model and its various gotcha's, there is something called a "compiler". And a compiler
> > will reorder loads and stores according to the language rules, typically assuming no multithreading
> > unless special annotations are added (eg. volatile, intrinsics or the C++11 atomics).
> >
> > Whatever memory model you're targeting, you always need
> > those annotations. When annotated correctly there is
> > actually little difference between the different memory
> > models - some annotations cause special loads/stores
> > to be emitted, some become barriers, some are just nops
> > and only compiler optimization barriers. So it is more
> > correct to say that compilers will automatically take advantage
> > of the memory model when supplied with correct
> > annotations. They can even optimize away redundant barriers when they can prove they aren't required.
>
> That's true, but writing those annotations are f***ing hard, so, as I
> understand Linus is asking for a clear behavior for variable load.
The annotations are easy: pthread_mutex_lock(), pthread_mutex_unlock(), etc.
(Or whatever synchronizatoin library or language features you are using).
If you get them wrong, then you have bigger problems than the memory ordering. If you get them right, then the memory ordering is done for you.
If people try to "roll their own" synchronization code without understanding memory ordering and language rules, then I really can't see why anybody has such sympathy for them. It would be like if they tried to write the code in assembly without knowing what the machine instructions do. Or writing a device driver without understanding the MMIO ordering rules. Or writing synchronization code without understanding what an atomic read-modify-write instruction does.
"Programmers who don't understand how this works *may* end up with *slightly* fewer bugs in their code than other memory ordering models." is NOT a feature.
>
> But actually those annotations are required even on x86 with the most conservative
> compiler, on more aggressive compilers many of those annotations become just useless
> because the C standard is so stupid in requiring so few guarantees for them.
Also because x86 can visibly reorder memory accesses.
> Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on July 13, 2015 4:36 pm wrote:
> > The point is, you can't. Ignoring the fact most people wouldn't understand the intricate details of
> > say the x86 memory model and its various gotcha's, there is something called a "compiler". And a compiler
> > will reorder loads and stores according to the language rules, typically assuming no multithreading
> > unless special annotations are added (eg. volatile, intrinsics or the C++11 atomics).
> >
> > Whatever memory model you're targeting, you always need
> > those annotations. When annotated correctly there is
> > actually little difference between the different memory
> > models - some annotations cause special loads/stores
> > to be emitted, some become barriers, some are just nops
> > and only compiler optimization barriers. So it is more
> > correct to say that compilers will automatically take advantage
> > of the memory model when supplied with correct
> > annotations. They can even optimize away redundant barriers when they can prove they aren't required.
>
> That's true, but writing those annotations are f***ing hard, so, as I
> understand Linus is asking for a clear behavior for variable load.
The annotations are easy: pthread_mutex_lock(), pthread_mutex_unlock(), etc.
(Or whatever synchronizatoin library or language features you are using).
If you get them wrong, then you have bigger problems than the memory ordering. If you get them right, then the memory ordering is done for you.
If people try to "roll their own" synchronization code without understanding memory ordering and language rules, then I really can't see why anybody has such sympathy for them. It would be like if they tried to write the code in assembly without knowing what the machine instructions do. Or writing a device driver without understanding the MMIO ordering rules. Or writing synchronization code without understanding what an atomic read-modify-write instruction does.
"Programmers who don't understand how this works *may* end up with *slightly* fewer bugs in their code than other memory ordering models." is NOT a feature.
>
> But actually those annotations are required even on x86 with the most conservative
> compiler, on more aggressive compilers many of those annotations become just useless
> because the C standard is so stupid in requiring so few guarantees for them.
Also because x86 can visibly reorder memory accesses.