The more the merrier - maybe.

After reading what Chuck House had to say on Data Visualisation and Mapping I pondered other problems in the computer science field. One item that seems to pop up regularly is parallel computing especially as it applies to multi core processors. I watched a lecture recently (CS and E / Univ. Wash.) that mentioned this issue. It may have been Ed Lazowska. In any event the take away message was that concurrency in multi core software development was the biggest challenge in computer science today.

I am a bit incredulous that this could be so. I would have thought IBM et al with the massive parallel machines would have this in the bag. Not so apparently. Although the new IBM Multicore SDK for Java may have addressed some of the issues. I have not looked at it yet but it does seem to have design features I touch on below.

I'm not by any means a compiler writer or genius architect, and my previous dealing with multi user / re-entrant code was on the Wang minis. Mostly the hardware kept me safe as a babe in mothers arms, and I'm certainly no expert on Intel multi core, so if I screw this up - yell.

Being a 'database guy' I am familiar with multi-user record contention and potential race or lock conditions and I would have thought the techniques used in that field would be transplanted. Ed mentioned that up until the multi core days, developers (compiler writers etc) were insulated from changes to the MPU (barring new instructions). Now apparently all bets are off. If you want to use the entire horsepower, you must be very aware of concurrency issues such as race conditions, deadlocks, blocking and data protection.

I am reminded of the contention for the bathroom in the mornings. Get a house full of people (especially daughters) and the problem becomes evident. Of course you can always add bathrooms but that is like assigning a process to a single core. Playing with the affinity. But then everyone has their own stuff, no toothbrush, razor or data sharing. (in this case not such a bad thing).

Were we see these dangers now is the use of global variables. They can be changed from anywhere, usually by mistake and in a multi threaded or multi core environment this must be a nightmare to debug. However we know there are times when there is one piece of data that must be accessible to many asynchronous processes. A really common place to see this in action is with say, VB/VBA, multiple instances of a class may call a procedure in a standard module. (some procedures can not be located in a class) The code and data in the standard module is shared. One must used a 'collection' or stack in order to service the classes and keep state within a design not designed for concurrent or re-entrant operations.

Or perhaps a 'scheduling' or code logistics system that happens at the software development/compiler level. Similar in some respects to PCB autorouters only in the time, intersection and endpoint domain. The process flow is parsed, perhaps iteratively, dependencies and critical sections are mapped, worker threads / sub processes are slotted or allocated to the timeline / core to minimise contention issues. However the asynchronous interrupts or time slicing to 'foreign process' might produce anomalies, latency issues, in the cumulative delay. The new timing glitches. A bit like trying to pounce on that eBay item in the last few seconds only to find the latency increased for a second or so. aaaarrrggg!

Anyway, threads not impacted by absences due to 'foreign process' times might be allocated to cores reserved for that purpose. And critical section and data processing encapsulated in a single process with one core and everyone gets in line to be served. But that sort of defeats the purpose eh?

Then there is the matter of trust. You are hooked up to a heart-lung machine controlled by a multi core computer doing other things as well. Do you prefer Windows, OSX, Linux, UNIX or wimp out and go for the single threaded embedded RTOS system?

Gives a new meaning to Code blue (screen).

Then again a deterministic orthogonal system for the PC may not be possible. Multicore may turn out to be the new mythical man month.

It may be that the classic Von Neumann architecture has to go. We may need hardware support or partitioning to protect memory and orchestrate the 'locking' mechanism for shared data, and that this mechanism is abstracted by the compiler and the development architecture.

Goodbye to the 'IBM compatible' 'Wintel' architecture? probably. It was never developed, or envisioned, to be this multi gigabyte - multicore monster it has become. Amazing it has lasted as long as it has.

_