By: anon (anon.delete@this.anon.com), July 13, 2015 9:07 pm
Room: Moderated Discussions
EduardoS (no.delete@this.spam.com) on July 13, 2015 8:11 pm wrote:
> anon (anon.delete@this.anon.com) on July 13, 2015 6:43 pm wrote:
> > The annotations are easy: pthread_mutex_lock(), pthread_mutex_unlock(), etc.
>
> Very easy, put locks everywhere...
Yep. Locks where required. Or call into a scalable data structure or some other synchronization primitive like RCU or something.
>
> You are kind of missing the point.
I am not.
>
> > 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.
>
> Many times on this thread people come with the argument "most programmers are stupid and so you need
> simple rules", but, the best part, is the real world, where most programmers don't give a shit about
> performance and just put locks everywhere, but a few programmers care, they think they are better than
> everyone else, they even try to solve problems without locks, not just that, they try to help others
> by writing synchronization library! And as fun as it can get, sometime they get this wrong.
>
> You can say all stupid programmers have to do is to use a library, but what when
> the experts that wrote that libraries can't get the synchronization correctly?
You miss the point. They can and do. This is why everything you see around you works correctly today.
Everybody makes mistakes and introduces bugs. That is unavoidable fact of life. If you are programming on a weak ordered model, you will make bugs that are due to the weak ordering. You will make bugs due to all aspects of the platform you are programming on. Citing examples of such mistakes does not somehow "prove" it is the wrong approach.
If I point to a bug caused by x86 memory ordering, would that prove it is a poor choice? No.
>
> Many of the errors Linus talked about weren't done by stupid programmers which
> only lock everything, those errors where done by "experts" which knows the ordering
> rules, tried to be clever but failed because of some subtle details.
>
Of course. Do you know how many bugs the Linux kernel gets? Hundreds every release. Probably thousands. Crashes, data corruptions, security bugs. All caused by "experts" in storage, filesystems, network programming, etc. Does this make the kernel design wrong? The programming model wrong? The concept of a filesystem wrong? No. It doesn't.
> anon (anon.delete@this.anon.com) on July 13, 2015 6:43 pm wrote:
> > The annotations are easy: pthread_mutex_lock(), pthread_mutex_unlock(), etc.
>
> Very easy, put locks everywhere...
Yep. Locks where required. Or call into a scalable data structure or some other synchronization primitive like RCU or something.
>
> You are kind of missing the point.
I am not.
>
> > 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.
>
> Many times on this thread people come with the argument "most programmers are stupid and so you need
> simple rules", but, the best part, is the real world, where most programmers don't give a shit about
> performance and just put locks everywhere, but a few programmers care, they think they are better than
> everyone else, they even try to solve problems without locks, not just that, they try to help others
> by writing synchronization library! And as fun as it can get, sometime they get this wrong.
>
> You can say all stupid programmers have to do is to use a library, but what when
> the experts that wrote that libraries can't get the synchronization correctly?
You miss the point. They can and do. This is why everything you see around you works correctly today.
Everybody makes mistakes and introduces bugs. That is unavoidable fact of life. If you are programming on a weak ordered model, you will make bugs that are due to the weak ordering. You will make bugs due to all aspects of the platform you are programming on. Citing examples of such mistakes does not somehow "prove" it is the wrong approach.
If I point to a bug caused by x86 memory ordering, would that prove it is a poor choice? No.
>
> Many of the errors Linus talked about weren't done by stupid programmers which
> only lock everything, those errors where done by "experts" which knows the ordering
> rules, tried to be clever but failed because of some subtle details.
>
Of course. Do you know how many bugs the Linux kernel gets? Hundreds every release. Probably thousands. Crashes, data corruptions, security bugs. All caused by "experts" in storage, filesystems, network programming, etc. Does this make the kernel design wrong? The programming model wrong? The concept of a filesystem wrong? No. It doesn't.
