CONCURRENCY

From A Robot in Every Home by Bill gates

One such technology will help solve one of the most difficult problems facing robot designers: how to simultaneously handle all the data coming in from multiple sensors and send the appropriate commands to the robot’s motors, a challenge known as concurrency. A conventional approach is to write a traditional, single-threaded program–a long loop that first reads all the data from the sensors, then processes this input and finally delivers output that determines the robot’s behavior, before starting the loop all over again. The shortcomings are obvious: if your robot has fresh sensor data indicating that the machine is at the edge of a precipice, but the program is still at the bottom of the loop calculating trajectory and telling the wheels to turn faster based on previous sensor input, there is a good chance the robot will fall down the stairs before it can process the new information.

Concurrency is a challenge that extends beyond robotics. Today as more and more applications are written for distributed networks of computers, programmers have struggled to figure out how to efficiently orchestrate code running on many different servers at the same time. And as computers with a single processor are replaced by machines with multiple processors and “multicore” processors–integrated circuits with two or more processors joined together for enhanced performance–software designers will need a new way to program desktop applications and operating systems. To fully exploit the power of processors working in parallel, the new software must deal with the problem of concurrency.

The problem of concurrency is essentially a problem of coordinating multiple systems to work together simultaneously with a single, unified goal. This is a problem that biological systems solved millions of years ago. It seems a bit to hasty to suggest that the solution to this problem is to be found in generating software to handle multiple systems; from a naive perspective, it seems a solution also rests on getting the hardware to operate in parallel. This may be a concession to theorists who strictly oppose the computationalist paradigm, since it seems to lend weigh to the idea that the way a system is embodied can influence its abilities to act in the world.

I need to think about this more, since my current discussion of users rests on a theory of participation and co-operation that appears to address the problem of concurrency. So marking this for future discussion.