Jul 092011
 

Threading is on the front pages more than ever, so to speak. Where only a few years ago programmers could brush the topic aside as complicated and not-very-useful, it’s increasingly harder to hide behind those excuses. Multi-core systems are the status quo and the only real way to get better performance (read: scale) is to have multi-threaded code.

So it’s no surprise that the topic is revived and there is more talk about it. And what threading if one doesn’t mention the pitfalls and problems? Consider the following question:

int x = 1;
int y = 0;

if (y == 0)
{
   // Can x be anything but 1 at this point?
}

There is no shortage of this type of questions. And there is no shortage of answers either!

The only correct answer to the above question is: It depends on the language!

What does the keyword volatile do? Same answer.

Does my code suffer from the ABA problem? Same answer (but that one is more complicated)

Similar question, same answer.

// Thread 1
x = 1;
y = 0;

// Thread 2
int a = x;
int b = y; // if b == 0, is a == 1?

Here is a pdf presentation of a lock-free hashtable in Java. Here is the video presentation. Again, if the same algorithm implemented in a different language, the result will be different. Namely, it won’t work.

Why? Because the memory models are different. C++ has a very, very different memory model than .Net than Java. (It wouldn’t be entirely wrong to say that C/C++ don’t define any memory coherency models as such.) Each in their turn probably have a different memory model from other languages. And talking about threading without knowing the memory model is like assuming you can drive at the same speed on all roads. Well, some aren’t even paved, yet some have minimum speed.

It’s very unfortunate that an already complex subject is made even more confusing by the differences in languages and their guarantees, or lack thereof. There is no shortage of confused, misleading and downright incorrect information when it comes to threading. Consider that locks don’t even protect your code against out-of-order execution. But in which language is that?

This is made even more complicated by the fact that processors and hardware architectures come with their own set of guarantees and reservations. So reading on those without taking into account what the language in question abstracts from the hardware, is yet another way to throw oneself in the rabbit hole.

So, the next time you read (or write) about threading issues, make sure you know which language is in question. If it doesn’t say, stop reading. Without that small one-word detail, everything you learn is wrong, regardless of how detailed and coherent it is. Because precise doesn’t necessarily mean accurate.

Share

  4 Responses to “(Almost) Everything You Read About Threading Is Wrong!”

  1. In spite of what proggit commenters might say, I think your point is very clear: make sure you know which language is in question when reading about threading.

    Like or Dislike: Thumb up 1 Thumb down 0 (+1)

    • Thanks Glenn!

      Communicating ideas clearly isn’t at all trivial, as I’m learning. I should try to improve how I present my ideas to reach a wider audience. In this case the point was simple and mostly obvious yet I failed to click with redditors. I just wish there is more dialog/critique rather than the silent voting. However, this post got much better responses on other sites.

      Like or Dislike: Thumb up 0 Thumb down 0 (0)

  2. [...] (Almost) Everything You Read About Threading Is Wrong, ashodnakashian [...]

    Like or Dislike: Thumb up 0 Thumb down 0 (0)

  3. [...] (Almost) Everything You Read About Threading Is Wrong! [...]

    Like or Dislike: Thumb up 0 Thumb down 0 (0)

 Leave a Reply

(required)

(required, not public)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

 

QR Code Business Card