It is a real pleasure to tell you this slightly crazy fact. I will be on a panel at the upcoming IDF. Why, you might ask? Well, the reason is that this panel is discussing an issue that may be a major concern and interest to everyone working in the field of computer science today: that  parallel programming is rarely being taught in our undergraduate programs. Why is it not being taught or addressed in many cases? You will hear many differing options to this: “what language should we teach?”, “parallel programming is too hard”, “but if we teach parallel programming we will have to drop something else”, and on and on. All of these questions and issues are valid and there is no single answer and there is clearly no easy answer. So we all need to be standing on the roof tops and shouting out ideas, as we need to address this problem now, not in 2 or 5 years down the line.

The panel “Parallel Education Status Check – Which Programming Approaches Make the Cut for Parallelism in Undergraduate Education?” is intended to bring people from industry and universities together (there will be another at SC’11 in November), to voice their views on this important topic. I am happy to say that as part of my work with the Educational Alliance for a Parallel Future (EAPF) working group, I have had the chance to work with some outstanding people on this issue and this panel brings some of them together to express their options and ideas on this important topic. Each panelist has been asked to develop a position statement for the panel with a goal of producing strong views and discussions and the following is my attempt to do this.

The move towards “Multicore” and “Manycore” has again pushed the envelope in computer science for the development of new programming languages and paradigms, but is this really what’s needed?

New languages and paradigms can make it hard for educators to know what they should teach. There are too many programming languages to mention, each of which has its advantages and disadvantages, but many of them lack concurrency abstractions, and ones that do have them often emit a strong model for reasoning about communication and shared access to data.

The last few years have seen an effort to define stronger memory models for shared memory programming with respect to data race free programs (DRF), c.f. Java and C++11, and with this direction comes hope. Not because DRF shared memory programming is necessarily the final answer but because it looks beyond a particular programming language or paradigm and instead tries to address the fundamentals of building software for “Multicore” and “Manycore” machines, by providing clear semantics for when and how data can be shared with others.

With this in mind it is not what programming language should be taught, but the foundations, architectures, memory models, design patterns, and so on that lead the next generation of students to develop applications that can scale from today’s “Multicore” and “Manycore” systems to tomorrow’s one zillion core machines.

Benedict R. Gaster is a Software Architect at AMD. His postings are his own opinions and may not represent AMD’s positions, strategies or opinions. Links to third party sites, and references to third party trademarks, are provided for convenience and illustrative purposes only. Unless explicitly stated, AMD is not responsible for the contents of such links, and no third party endorsement of AMD or any of its products is implied.