hi,something about thread in perl

[Ben Morrow]

i 'd like to write threaded perl program in a IBM machine which contain
8 cpu and install AIX 5.1 .

i look at the perlthrtut , and find perl thread is just like the fork in
unix, which is expensive.

Yup

is perl thread in user-mode or kernel mode? AIX 5.1 support kernel
thread, and can automatic put the task to all processers.but user thread
only can do all work in one processer. and if perl thread is only
running in one processer, it 's senceless for me to do thread program.

Perl threads under unix will use your pthreads (POSIX threads)
implementation, so if your system pthreads library uses kernel threads
(and I'd bet it does, on AIX) then perl will too.

However, as you say, a perl thread is not a thread by any reasonable
definition: it's a userland fork. Without copy-on-write, or any of the
other optimizations the kernel can provide. The ithreads concept
originated in a project to emulate fork on systems which don't support
it, and IMHO on a system which supports fork you'd be *much* better off
with that. You *may* find that if you can create all your threads at
startup that over the course of a long-running program saving the
context switches needed for multiprocess is a significant benefit over
fork, but I doubt it; especially if you aren't forking hundereds of
process but just ~1 per processor.

If you want to use the threads::shared interface while forking, see the
forks module on CPAN.

Ben

 

[XiaotingHua]

i 'd like to write threaded perl program in a IBM machine which contain
8 cpu and install AIX 5.1 .

i look at the perlthrtut , and find perl thread is just like the fork in

unix, which is expensive.

is perl thread in user-mode or kernel mode? AIX 5.1 support kernel
thread, and can automatic put the task to all processers.but user thread
only can do all work in one processer. and if perl thread is only
running in one processer, it 's senceless for me to do thread program.

any advise? thank you!

 

[sam]

Quoth XiaotingHua <[email protected]>:

However, as you say, a perl thread is not a thread by any reasonable
definition: it's a userland fork. Without copy-on-write, or any of the
other optimizations the kernel can provide. The ithreads concept
originated in a project to emulate fork on systems which don't support
it, and IMHO on a system which supports fork you'd be *much* better off
with that. You *may* find that if you can create all your threads at
startup that over the course of a long-running program saving the
context switches needed for multiprocess is a significant benefit over
fork, but I doubt it; especially if you aren't forking hundereds of
process but just ~1 per processor.

I m more concern the required memory when dealing with million of
processes that created by fork().

Sam.

 

[Ben Morrow]

I m more concern the required memory when dealing with million of
processes that created by fork().

ithreads copy all perl data structures, without sharing pages. (This is
something that is being worked on, though...) I would expect (though I
haven't checked) a given number of ithreads to use (much) more memory as
well as being slower than a given number of forked processes, again
assuming a vaguely modern Unix OS.

Ben