Error on page 15 of IEEE Software Jan/Feb 2011
Dear Forest Shull (editor of IEEE Software)
There is an error at that page, in the article “Parallelism on the Desktop” (Guest Editors’ introduction: Victor Pankratius, Wolfram Schulte and Kurt Keutzer [1]). The authors have virtually fallen into the same trap as many programmers working with concurrency or parallelism.
“If the shared resource is mutable, programmers must introduce exclusion mechanisms, such as locks in C++ or synchronized methods in Java, to prevent race conditions (where two or more threads change the resource at the same time and introduce an inconcistent state).”
In order to be correct, the last part may instead read: “where even a single writer and a concurrent single reader may introduce an inconcistent state”.
The principle is called CREW (Concurrent Read Exclusive Write), see http://en.wikipedia.org/wiki/Concurrent_read,_concurrent_write: “Concurrent Read Exclusive Write (CREW) — multiple processors can read a memory cell but only one can write at a time”.
The idea of the concurrency primitives is to avoid this type of situation. In the problem domain, CREW shows how bad it is. In the solution domain, it would be the accesses (read or write) that need protection if there is at most one writer.
I may blog about this error at http://oyvteig.blogspot.com/ any day soon. (Done, with minor edits.)
[1] - Read pdf (4 MB)
Dear Forest Shull (editor of IEEE Software)
There is an error at that page, in the article “Parallelism on the Desktop” (Guest Editors’ introduction: Victor Pankratius, Wolfram Schulte and Kurt Keutzer [1]). The authors have virtually fallen into the same trap as many programmers working with concurrency or parallelism.
“If the shared resource is mutable, programmers must introduce exclusion mechanisms, such as locks in C++ or synchronized methods in Java, to prevent race conditions (where two or more threads change the resource at the same time and introduce an inconcistent state).”
In order to be correct, the last part may instead read: “where even a single writer and a concurrent single reader may introduce an inconcistent state”.
The principle is called CREW (Concurrent Read Exclusive Write), see http://en.wikipedia.org/wiki/Concurrent_read,_concurrent_write: “Concurrent Read Exclusive Write (CREW) — multiple processors can read a memory cell but only one can write at a time”.
The idea of the concurrency primitives is to avoid this type of situation. In the problem domain, CREW shows how bad it is. In the solution domain, it would be the accesses (read or write) that need protection if there is at most one writer.
I may blog about this error at http://oyvteig.blogspot.com/ any day soon. (Done, with minor edits.)
[1] - Read pdf (4 MB)
.
