When starting to write this post, I remember that July was a really busy month, without new posts on JungleCoders. But it was a month where I returned to reading about the issues of today about multiprocessing. A few years ago, there were fewer processors than users :-) It was the time of large computers or mainframes.

With the arrival of the personal processor, began the era of one-to-one, but they were small machines, with simple operating systems. Although there was a processor per user, there was no system operating system, much less resources on hardware to support task switching. Of course, for home computers, as super-micros and complete operating systems such as Unix already existed.

With the evolution of Microsoft DOS and IBM PC, programmers began to use hardware interrupts to simulate multiprocessing, it was the era of TSRs (Terminate and Stay Resident). Who never used programs like Norton Guides or Sidekick? But the most popular were those login things that stay in the upper right corner of the screen. Every DOS programmer had to implement one… Ok, Mingo can say that the Amiga already had real multitasking, but few lucky ones had access to these systems.

To save the lineage of IBM PC, Intel came out with the 80286. But poor DOS continued to be monotask, except for TSRs… IBM launched OS / 2 and renewed hopes of a multitasking system for mortals. For companies, Novell Netware and variants of Unix already existed. With the arrival of Intel 80386 things got really serious and Windows 3.0 began to convince that multimedia would be the future. The new system allowed multiple applications to run at the same time, but could not be misbehaved. If a task resolved to take over the operating system for itself… we discovered it was multitasking cooperative… it was the end. New versions of OS / 2 emerged with a new term, preemptive multitasking. With preemptivity, the operating system could regain control of the machine, even if one of the tasks did not contribute much to this.

Well, OS / 2 never really caught on for home users, being relegated to small corporate fiefdoms and second-hand urban legends surviving to this day in banks. Windows 95 brought preemptivity to Microsoft systems and for us poor users. The big problem is that sometimes the operating system froze… leave it in the past :-) The system has stabilized and now we have other types of problems. Home computers have 2 or 4 processors and systems like Windows XP and Linux have taken care of using these resources, but with a restriction: if the application is developed with a single thread, this cannot be distributed to more than one processor :-( It may seem little, but if you do not take care, the application will run more slowly on a machine with two processors.

The big question today is how to write programs for this new world? Now we have multiple processors for our applications, but programming with threads is still difficult. Some people believe that there is a need to change the way we program today. Others believe in intelligent compilers capable of deciding which parts of the code can or cannot be executed in parallel. Despite not being a big problem, Intel has signaled that it already has processors with 80 cores in the lab. Imagine one day having such a machine and your poor program running at only 1/80 of the total power of the machine :-) ?

Since nothing is accepted by everyone at the same time, there are already several approaches to this problem. One of them is to use other programming languages with different paradigms like Erlang or Haskell. My poor Python is far from this. According to the Guido, the solution is to use multiple processes and live in the haunted house of IPC (Inter-process Communication). As far as I know, Ruby is even worse in this regard. Java, C / C ++ / C # ( * .net) are fine, but all the pain of multiple threads remains for the programmer.

A light comes from the world of games, since the graphics processors of video cards have more than 30 pipelines. Running at over 500 MHz, these processors go unused when we’re not playing, a wasted power processing. Both Nvidia and ATI promised to publish compilers for their GPUs, but warned that the way to program is different.

Who has worked with IPC and threads knows that it can be done, but not for free. As software has become more complex, how will we solve the problem of creating software capable of taking advantage of the resources of multiprocessor machines? I personally believe in using languages with new paradigms that provide abstraction of threads, but deep down I wish something new emerges in the area of compilers and all of us can continue to program as always.