The Future of Python Threading

[Ben Sizer]

On 10 Aug, 15:38, Ben Finney <bignose+hates-s... at benfinney.id.au>
wrote:
> "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.

--
Ben Sizer