Tomas Evensen

RDC in China

I just came back from a couple of weeks in China. Fascinating country. Besides the usual customer visits, we also held three Regional Development Conferences (RDCs) in Shenzhen, Shanghai and Beijing.

The RDCs were a huge success with on average more than 400 attendees per day. And they were all very interested in hearing about Wind River's latest offerings and future plans.

How do I know they all were interested? Well, my leading indicator was that all seats were taken from the front working towards the back. Somewhat different from your typical American or European conference, where the back seats seem to be the hottest commodity. (BTW, I am of course not indicating that our American and European friends are not interested... Perhaps they have better eye sight )

  Paul Chen on stage in Shenzhen

We discussed in some detail the various components of Wind River's Platforms, including new features of our VxWorks, Linux, WorkBench and Diagnostics offerings. If you haven't seen it already, we just released a new version of our platforms, so there was plenty to talk about. I also had an opportunity to go into some detail about our multicore/multiprocessing offerings. That tied nicely into a presentation from FreeScale about their multicore plans.

Judging from the amount of questions in the QA section and the questions I got afterward, multicore is getting huge in China. A lot of discussion whether Asymmetric Multiprocessing (AMP) or Symmetric Multiprocessing (SMP) is "better". As with many things in life, there is not a simple answer to that question more than the unsatisfactory "it depends". It is really an area where there is a lot of confusion. The confusion starts at the definition level, where some people might define SMP as Symmetric Multiprocessors (meaning multiple processors that are identical but might or might not have separate OSes on top if them) while others define it as Symmetric Multiprocessing - meaning symmetrical processors handled by one OS. I'll talk about my views on when to use what in a future blog.

I continue to be impressed by the quality of the engineers in China. Very smart and creative. So impressed in fact that we decided to open a development center in Beijing. We have the first ten engineers on training in Alameda right now so that we can get a running start next year. The team will focus on doing BSP work for both our VxWorks and Linux platforms and I expect a lot of new exiting technology coming out of the group in the coming years. It is also a definite advantage to have developers close to your customers, something we have experienced again and again through our development centers around the US, Canada and Europe. Nothing beats that local first hand experience.

As for my other experiences in China I'll have to refer to the old saying, "what happens in Beijing, stays in Beijing"...

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 ;-)