Multicore in Systems Classes -- #2 Beyond "Parallel"

This topic has been mulling around in my head for a while, but it was really only in discussions with several people at SuperComputing a couple of weeks ago that I figured out how to explain what was bothering me.  As I mentioned in the last post in this series, I'm teaching a junior-level systems course this semester (and next).  There was already a certain amount of "parallel" content in that course before I took on my reform/upgrade/enhancement challenge... specifically, there was a series of lectures on pthreads hidden somewhere in the middle, and some discussion about concurrency issues in OS threads.

This is good stuff... and much of it is still in there in some form.  But Steven Parker of NVidia mentioned in a panel discussion at SC that, before he left academia,  he was doing something similar in one of his classes. Out of curiousity, he did an informal poll of many of his colleagues, and found that they, too, were trying to "be good" to their students by covering parallelism... and almost all of them were covering the exact same pthreads lectures.  Depending on your institution's choice of languages, you could equally well substitute java threads or windows threads in there, too.

(shameless plug -- you can watch the panel here: http://software.intel.com/en-us/videos/preparing-the-world-for-ubiquitous-parallelism-at-sc09-part-1/)

So, as important as it is to transition from no parallelism to having some parallelism in your curriculum, it's also very important that you make sure that you balance that with some depth and breadth of exposure.  So, concretely, I took the pthreads section (which, incidentally, mirrored what was in both their sophomore- & senior-level class) and tried to deconstruct it.  I grabbed a copy of the slides from the sophomore class, replayed a subset of them (the simple banker's mutex example), and then asked them to explain how the OS could be offering this service.

We (eventually, with some professorial prodding) dug all the way down to discussions of atomic instructions, and the cooperation between the memory & cpu that they require.  I then challenged them, as they walked out the door, to think about what happens in multicore systems where it may no longer be practical to think about locking the whole memory bus -- i.e. what happens to mutexes (and the whole pthreads model) if compare-and-swap dies?

The point here is to emphasize that parallelism as we in the community are used to defining it is a good starting point... but isn't necessarily sufficient for where our students need to go.  As useful as the multi-threaded web server is as a project (for example), it's not likely to be typical of the way students have to think about parallelism in the future in order to deal with multicore chips.  So we have to stretch... find some ways to channel new challenges and opportunities into the classroom, even if we don't know which way the technological ball will end up bouncing.
Per informazioni più dettagliate sulle ottimizzazioni basate su compilatore, vedere il nostro Avviso sull'ottimizzazione.
Contrassegni: