I'm a bit disappointed that the article doesn't explain the need for a memory/consistency model and how it interacts with CPU caches. Locks are the easy part, and the article makes you think that with them you can now write at least simple concurrent programs.
Why is that? I'm pretty sure that the author's intention is not to equip the readers with the tools to make buggy programs, yet that is exactly what happens here.
Yes. As long as you use correctly-constructed synchronization primitives (e.g. pthreads), you don't need to worry about memory consistency.
When you need to start worrying is when you start implementing your own synchronization (either rolling your own primitives or going lock-free).
'moring needs to clarify what they are talking about. It's perfectly possible to write correct code using pthreads on modern hardware with no understanding of memory consistency.
Comments
I'm a bit disappointed that the article doesn't explain the need for a memory/consistency model and how it interacts with CPU caches. Locks are the easy part, and the article makes you think that with them you can now write at least simple concurrent programs.
Why is that? I'm pretty sure that the author's intention is not to equip the readers with the tools to make buggy programs, yet that is exactly what happens here.
Don't the standard synchronization APIs documented in the article handle memory barriers for you?
Yes. As long as you use correctly-constructed synchronization primitives (e.g. pthreads), you don't need to worry about memory consistency.
When you need to start worrying is when you start implementing your own synchronization (either rolling your own primitives or going lock-free).
'moring needs to clarify what they are talking about. It's perfectly possible to write correct code using pthreads on modern hardware with no understanding of memory consistency.