Today on the Coverity Development Testing Blog‘s continuing series Ask The Bug Guys, I answer a question I’ve gotten a fair number of times recently: how is it possible to implement locking without already having locking?
The answer I give is chock full of lies, misinformation and oversimplification, but hopefully it will get across the basic concept that you can build all the threading mechanisms out of simple parts like atomic-test-and-set.
In related news, here are a couple of other recent posts to ATBG. First, my colleague Tim explains that Java’s
hashCode has many of the same design guidelines as the equivalent method in C# that I discussed here. And my colleague Jon discusses the perils of accidentally performing overlapping reads and writes to the same buffer in C. [1. My favourite quotation on the subject of poor handling for overlapping buffers has to be “there has yet to be an example of an application whose impressive performance can be credited to the absence of overlap-detection code in memcpy“. True that! I note also that the C# equivalent
Array.Copy method is documented as dealing correctly with overlapping reads and writes to the same array.]
As always, if you have questions about a bug you’ve found in a C, C++, C# or Java program that you think would make a good episode of ATBG, please send your question along with a small reproducer of the problem to
TheBugGuys@Coverity.com. We cannot promise to answer every question or solve every problem, but we’ll take a selection of the best questions that we can answer and address them on the dev testing blog every couple of weeks.