Everyone knows that, when it comes down to it, it's all about the threads. Now, most coders ... they only use a single thread. Heck, some probably don't even realize that they're even codin' on a thread. All they know is that they write code, the computer runs it, and that's that. But the true, hard-core, and if I may say, gangsta' coders ... *they* go multi-threaded.

Brian K is a Senior Software Engineer which, I believe, makes him a gangsta' coder. A few years ago, he joined one of the larger security system companies to help them complete their latest and greatest security system. They were behind schedule, primarily with the Security Messaging Engine, which was the subsystem responsible for routing and distributing massive quantities of data from keycard usage, proximity sensors, and a whole host of other software and hardware.

On his third day on the job, Brian met with Jerry, the lead developer for the SME, in order to learn more about the project and the main man behind it. Jerry seemed like a nice guy; he had "20 years of C++ experience," which, at the time, was older than C++ itself. He went on to explain the two main issues with the SME subsystem.

The first problem Jerry was having was that the SME wasn't working on their target UNIX platform. Brian thought it was a bit odd and asked Jerry how he had developed it. Jerry responded, "using VC++6 and the MFC libraries."

Assuming that Jerry was being sarcastic, Brian replied "heh, well that should be easy; just use the UNIX Win32 library."

But Jerry, as it turns out, wasn't joking. Brian, still being a nice guy, explained that you can't use MFC if you ever want to compile something outside of Windows. "Huh," Jerry responded, "I’ve only used Windows and, besides, isn't UNIX based on Windows."

Fortunately, things went uphill from there. Brian explained to his boss that Jerry was not as much of a gangsta' coder as everyone had originally thought. This came as a large surprise, especially since Jerry was known for his Threads ... as in thread-sssss (plural); Jerry developed multi-threadedly. All it took was a few samples of Jerry's multi-threaded code to show the bosses how well Jerry did threads ...

When he reviewed the code, Brian noticed was that there were a lot of copy/pasted functions, many in completely different coding styles. On a whim, Brian did a quick google search on one of the functions. And then another. And then another. After only a few minutes of searching, Brian found code from nine different articles, all posted on a certain website known best for its presentation of astonishingly low-quality, unedited articles and code samples.

The patchwork of code also explained the second problem: strange and unreproducable routing errors with bizzare and mixed-up messages. It turns out that Jerry must have missed the articles on semaphors, locking, mutexes, and all those other complexities with multi-threading programming that I'm not even gangsta' enough to talk about. But it's hard to say if that's even "The Real WTF" or not.

Using one of the examples he found, Jerry's code spawned a listener thread when the main program started. This listener thread would wait for a connection on a 10ms timer and, if a connection was received, spawn a new listener thread and then process the message. This was done recursively, once for each inbound connection and worked especially interesting considering the "massive amounts of data" the system received. I present to you only a small snippet of this logic ... 

public int ProcessIncomingMessage
  (int messageId, int messageType, char* message)
{
  //spawn a new listener so we can process this
  int h = CreateThread(
    NULL, 0, ListenForMessage,
    (void *)this, 0, NULL);

  //now process the message
  int result = -1;
  switch (messageType)
  {
    case MSGTYP_M001:
      result = ProcessCvlMessage(messageId, message);
      break;
    case MSGTYP_M002:
      result = ProcessAplMessage(messageId, message);
      break;
    case MSGTYP_M003:
      if (this->routingLevel == 1)
        result = ProcessLcxMessage(messageId, message);
      else
        result = ReRouteMessage(messageId, MSGTYP_M008, message);
      break;

    --- snip ---

After they let Jerry go, Brian spent two months rewriting the entire subsystem from scratch, taking full advantage of the C++ Standard Library instead of MFC. And this time, the SME compiled on both Windows and UNIX, didn't mix up messages, and was monumentally faster than its predecessor. Brian, you are a true, hard-core gangsta' coder.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!