On 10 Aug, 15:38, Ben Finney <[EMAIL PROTECTED]> wrote: > "Justin T." <[EMAIL PROTECTED]> writes: > > The truth is that the future (and present reality) of almost every > > form of computing is multi-core, and there currently is no effective > > way of dealing with concurrency. > > Your post seems to take threading as the *only* way to write code for > multi-core systems, which certainly isn't so. > > Last I checked, multiple processes can run concurrently on multi-core > systems. That's a well-established way of structuring a program.
It is, however, almost always more complex and slower-performing. Plus, it's underdocumented. Most academic study of concurrent programming, while referring to the separately executing units as 'processes', almost always assume a shared memory space and the associated primitives that go along with that. > > We still worry about setting up threads, synchronization of message > > queues, synchronization of shared memory regions, dealing with > > asynchronous behaviors, and most importantly, how threaded an > > application should be. > > All of which is avoided by designing the program to operate as > discrete processes communicating via well-defined IPC mechanisms. Hardly. Sure, so you don't have to worry about contention over objects in memory, but it's still completely asynchronous, and there will still be a large degree of waiting for the other processes to respond, and you have to develop the protocols to communicate. Apart from convenient serialisation, Python doesn't exactly make IPC easy, unlike Java's RMI for example. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
