Intel and Multicore Tools

Intel is releasing tools to help programmers to deal with multicore. See the news.com story: Intel: Optimize applications for multicore. In the the article, James Reinders states that "It's not intrinsically harder to write threads, but developers need to get used to thinking that way and we need help from the tools." While I agree that developers need to get used to thinking that way, I actually do believe that it is intrinsically harder to write multi threaded applications. And I have the grey hair to prove it...

This begs the question, "Why is it so different to develop for multicore compared to a single core (or unicore)?".

Well, one of the reasons is that most software is written in a very serial fashion. This means that the sequence of the things a program is dealing with is very well defined and controlled. Programmers like that. No surprises due to timing and debugging is fairly straight forward. You can often use the normal paradigm of setting a breakpoint, stopping the code, look around and continue.
If you want to get any more horse power out of a multicore, you need to execute tasks in parallel. No use of adding that extra core if it sits idle while the first core is executing your neat serial program. To execute in parallel means that you have to split up the computations into separate threads that run concurrently. And we all know it is hard to do many things at once, especially if you are male (well, maybe that's a myth and even more so if you are an ex-president.

In programming, the difficulties with multitasking shows up when you are sharing data and multiple tasks are accessing the data at the same time, as exemplified by the traditional ticket booking problem. Here is a racing condition that would occur if the database that holds the number of tickets left for an event is not protected:

• Tickets in database(TicketsLeft): 10
• Ticket agent A reads TicketsLeft: 10
• Ticket agent B reads TicketsLeft: 10
• Ticket agent A subtracts 1 and writes back: 9
• Ticket agent B subtracts 1 and writes back: 9
• Tickets in database: 9

This way you got two tickets for the price of one!

The typical way to protect against this is through some sort of lock, to make sure that B does not access TicketsLeft until A is done. That is what mutual exclusion and semaphores are all about. The flip side of semaphores are that the more things you protect, the more likely you get two tasks waiting for each other, also called deadlocks.

Read more about racing conditions, deadlocks and semaphores at wikipedia.

There are two reasons why multitasking issues like the ones described becomes much more of a serious problem in multcores:

1. In multicores, you need to use multiple tasks to get performance gain, while in a unicore you can keep it simple
2. Multitasking applications tend to display any race conditions much more often on a multicore due to the higher probability that the critical code is actually executed in parallel. On a unicore you only get exposed when the timer interrupt happens at a very unfortunate time.

Tools, like the ones from Intel and HP will help you detect these issues by keeping track of semaphores and memory accesses. They are not fool proof, but any help you can get is good.

In the Wind River portfolio, we have a new great tool that will help you find threading problems as well as other very tricky problems. The tool I am thinking about is Workbench Diagnostics. With this tool you can dynamically, without stopping the system, insert code (sensor points) that can execute at any line of code and log any information you are interested in. For example, you can very easily create a sensor point where you put in some C code that will check whether a particular semaphore is taken when you access some data.

I strongly believe that tools like Workbench Diagnostics is the way most people will debug complex problems in the future. Any time you have a timing problem, and the most difficult problems to fix are timing problems, it becomes very hard to stop the system and do the traditional debugging with break points. Sensor points provide the ultimate printf debugging capability ;-)