Parallel Python

[Sergei Organov]

nmm1 at cus.cam.ac.uk (Nick Maclaren) writes:

> In article <mailman.2544.1168455985.32031.python-list at python.org>,
> Sergei Organov <osv at javad.com> writes:
> |> 
> |> Do you mean that POSIX threads are inherently designed and implemented
> |> to stay idle most of the time?! If so, I'm afraid those guys that
> |> designed POSIX threads won't agree with you. In particular, as far as I
> |> remember, David R. Butenhof said a few times in comp.programming.threads
> |> that POSIX threads were primarily designed to meet parallel programming
> |> needs on SMP, or at least that was how I understood him.
>
> I do mean that, and I know that they don't agree.  However, the word
> "designed" doesn't really make a lot of sense for POSIX threads - the
> one I tend to use is "perpetrated".

OK, then I don't think the POSIX threads were "perpetrated" to be idle
most of time.

> The people who put the specification together were either unaware of
> most of the experience of the previous 30 years, or chose to ignore it.
> In particular, in this context, the importance of being able to control
> the scheduling was well-known, as was the fact that it is NOT possible
> to mix processes with different scheduling models on the same set of
> CPUs.  POSIX's facilities are completely hopeless for that purpose, and
> most of the systems I have used effectively ignore them.

I won't argue that. On the other hand, POSIX threads capabilities in the
field of I/O-bound and real-time threads are also limited, and that's
where "threads that are idle most of time" idiom comes from, I
think. What I argue, is that POSIX were "perpetrated" to support
I/O-bound or real-time apps any more than to support parallel
calculations apps. Besides, pthreads real-time extensions came later
than pthreads themselves.

What I do see, is that Microsoft designed their system so that it's
almost impossible to implement an interactive application without using
threads, and that fact leads to the current situation where threads are
considered to be beasts that are sleeping most of time.

> I could go on at great length, and the performance aspects are not even
> the worst aspect of POSIX threads.  The fact that there is no usable
> memory model, and the synchronisation depends on C to handle the
> low-level consistency, but there are no CONCEPTS in common between
> POSIX and C's memory consistency 'specifications' is perhaps the worst.

I won't argue that either. However, I don't see how does it make POSIX
threads to be "perpetrated" to be idle most of time.

> That is why many POSIX threads programs work until the genuinely
> shared memory accesses become frequent enough that you get some to the
> same location in a single machine cycle.

Sorry, I don't understand. Are you saying that it's inherently
impossible to write an application that uses POSIX threads and that
doesn't have bugs accessing shared state? I thought that pthreads
mutexes guarantee sequential access to shared data. Or do you mean
something entirely different? Lock-free algorithms maybe?

-- Sergei.