"Making Multicore Work" Seminars

February has been a particularly busy month. So busy, in fact, that I was not able to make time to be at the Mobile World Congress in Barcelona. Instead I have spent most of the month completing a tour of seven European cities presenting at a joint Wind River/Freescale/Virtutech seminar series.

The theme of the seminar was "Making Multicore Work". The presentations included details of Freescale's newest and upcoming multicore devices, Virtutech's virtualised software development technology and Wind River's latest VxWorks SMP and multicore debug tools releases.

The subject of the seminar seemed particularly popular with the number and variety of attendees at each venue exceeding our expectations. Attendees included engineers and development managers from the Mobile Handset, Automotive, Defense and Networking industries.

The focus for my particular presentation was Symmetric Multi-Processing (more specifically VxWorks SMP) during which I outlined the challenges involved in programming for a multicore environment. I also presented a live demonstration of VxWorks SMP (running on the new MPC8572E based Freescale reference platform) in which I attempted to highlight those programming practices which may lead to problems in a multicore environment.

During my presentation I was keen to outline that problems may not only be caused by "bad" programming practices but may also be the result of apparently acceptable program structure which may fail due to assumptions made by the programmer. For example, programmers often expect memory operations to be performed in the order in which they appear in source code. However, modern processors use out-of-order execution [Wikipedia reference] techniques which may cause load/store operations to be re-ordered. In a single core system this is rarely (if ever) a problem due to the fact that the memory operation "pipeline" will be emptied/cleaned before or during the next context switch so the software knows little or nothing about the hardware optimisations happening beneath it. However, in a multicore system, where two or more tasks or ISRs are running concurrently, the programmer needs to be aware of the effect that out-of-order load/store operations may have and use appropriate memory barrier [Wikipedia reference] instructions where necessary. Without these memory barriers, out-of-order load/store operations on a multicore system could give rise to the worst kind of timing related bugs and race conditions.

I'm hoping that the audience at each of our venues took away something positive from the event. For myself, the event has reinforced my view that multicore devices will become increasingly commonplace over the next months and years. The attendance numbers and the reactions of attendees make it clear that engineers are being forced to think in terms of multicore (either Symmetric or Asymmetric multi-processing). The challenge for those engineers is to adapt the way they write code for a multicore environment whilst at the same time, fully utilising the hardware resources they have available.

Comments

[Michael]

Love the blog... but can you guys turn on full text feeds for those who use RSS readers?

Thanks!

[J B]

I wonder how the event compares to the NI and Intel Workshops?