Re: [patch] spinlocks: remove 'volatile'

[Benjamin Herrenschmidt]

> Please show me how that lock is safe without a compiler memory barrier! What's 
> to stop your compiler from moving loads and stores across your inlined lock 
> code?
> 
> When you add the missing compiler memory barrier, the "volatile" classifier 
> becomes unnecessary.
> 
> Actually, please just read the thread. We've been over this already. It's 
> starting to get really old.

This is also a very good example of why pretty much every time somebody
tries to implement lock-like primitives in userland without using
libpthread, they get them wrong... we recently had to debug for a
customer a library that typically had that sort of home-made "I know how
this works" kind of locks that were actually subtley broken on machines
with deep out of order store queues. Of course, we didn't have the
source to the library and the customer was blaming the processors and/or
linux for his bugs.

There should be a real big flashing warning at the very beginning of
every computer programming course, book, whatever, compiler etc...
"Don't ever try to do locking & atomic primitives yourselves" or
something like that... In fact, I would suggest gcc to warn every time
somebody writes a function that has "lock" in the name :) Ok... maybe
not, but heh.

>From my experience, this is a very common source of bugs especially in
threaded apps. People have fantasies that they can do locks faster than
the system libraries, or have this religious-class beleif that
libpthread is bad, or whatever and they get it wrong pretty much every
single time. They are often saved by x86 which is very much in order
still but even if that is changing.

In fact, in a former life when I was still porting windows
applications/drivers to MacOS, I think pretty much ever single time I
had to port some threaded app, it happend. Ugly. Drivers writers
occasionally got smarter and uses whatever primitives the NT kernel
provides (can't remember), possibly because that's what the sample code
does :) Apps were hopeless. Every single of them.

Ben.

-
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/