Re: Parallel Python

nmm1@xxxxxxxxxxxxx (Nick Maclaren) writes:

In article <mailman.2544.1168455985.32031.python-list@xxxxxxxxxx>,
Sergei Organov <osv@xxxxxxxxx> 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.

.

Relevant Pages

  • Re: Pthread problem using IRIX 6.5.4 with multiple processes
    ... I have noticed that the address space for POSIX Threads is shared. ... Does it mean that the kernel owns all the threads? ... I just wanted to know where the threads are saved in memory and if the ... >> I thought that the parent pid should differ from one process to another. ...
    (comp.programming.threads)
  • Re: kernel API mapping
    ... > onto RH linux, any hint where I can get some info in this regard, Thanks, ... For semaphores, look at the Posix Threads (pthreads) implementation. ...
    (comp.os.linux.development.system)
  • Re: thread mutexes
    ... In particular, the mutex lock/unlock functions. ... Unfortunately I think that POSIX threads are a dead end in some ways. ... NetBSD only provided a non-FIFO scheduler. ... and that means that pthreads can be deceptively simple. ...
    (comp.unix.programmer)
  • Re: e-book for thread Programming in C ????
    ... You need *YEARS* of experiences to master Pthreads... ... Programming With POSIX Threads, ... Unix System Programming: ... Kay Robbins, Steve Robbins. ...
    (comp.programming.threads)
  • Re: Thread and Task
    ... In VxWorks POSIX threads are not identical to tasks. ... block and bookeeping data. ... You can get pthreads in the kernel space ...
    (comp.os.vxworks)