The Future of Python Threading
kylotan at gmail.com
Fri Aug 10 17:37:34 CEST 2007
On 10 Aug, 15:38, Ben Finney <bignose+hates-s... at benfinney.id.au>
> "Justin T." <jmtull... at gmail.com> 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.
More information about the Python-list