ithreads - programming multithreaded applications in perl

Author

programming multithreaded applications in perl

Michael Suess

2005-06-08, 9:03 pm

Hi,

in the perlfaq1-manual, there is the following statement:

"For various reasons, Perl is probably not well-suited for real-time
embedded systems, low-level operating systems development work like
device drivers or context-switching code, complex multi-threaded
shared-memory applications, or extremely large applications."

Unfortunately, the reasons are not explained. I am a PhD-student at a research
group, where parallel processing is a big issue, and I was wondering if it
was possible and feasible to program parallel applications in so called
scripting languages, perhaps trading development time for performance in the
process. Well, it seems to be possible, as ithreads seem to be working. So I
was wondering, what these unexplained reasons are? Is there a document or a
posting somewhere, that state these explicitly? Or is this just plain old
information?

Thanks for your help,
Michael Suess

Robert Friberg

2005-06-08, 9:03 pm

Hi,

Threading is one of the few issues to be cautions about with perl.

Excerpt from perlthrtut:

"The main thing to bear in mind when comparing ithreads to other threading
models is the fact that for each new thread created, a complete copy of all
the variables and data of the parent thread has to be taken. Thus thread
creation can be quite expensive, both in terms of memory usage and time
spent in creation. The ideal way to reduce these costs is to have a
relatively short number of long-lived threads, all created fairly early on -
before the base thread has accumulated too much data. Of course, this may
not always be possible, so compromises have to be made. However, after a
thread has been created, its performance and extra memory usage should be
little different than ordinary code."

The entire document can be found here:

http://aspn.activestate.com/ASPN/do...perlthrtut.html

or by typing

perldoc perlthrtut

on a box with perl (>= 5.6.0) properly installed.

Also, you might want to check out POE, the Perl Object Environment.

http://poe.perl.org/

Absract from the POE whitepaper:

"POE is a toolkit for rapidly developing networking applications in Perl.
POE's
powerful multitasking framework lets applications perform several tasks at
once.
POE's message passing capabilities allow applications to be distributed
across a
network of machines. POE is mature, robust, and highly considered. POE is
free
and open, and can be field-customized for an organization's unique needs.
POE
is well supported by many people, and there exists a number of free
extensions
on the Comprehensive Perl Archive Network."

------------------------------------------------------------------------
! Robert Friberg 0733-839080
! Developer/Trainer perl,java,dotnet,linux,xml,uml,sql,c/c++,vb
! Ensofus AB http://www.ensofus.se/
! Miljö Online AB http://www.miljo-online.se/
------------------------------------------------------------------------

> -----Original Message-----
> From: Michael Suess [mailto:mike_ml@suessnetz.de]
> Sent: Thursday, June 17, 2004 3:59 PM
> To: perl-ithreads@perl.org
> Subject: programming multithreaded applications in perl
>
>
> Hi,
>
> in the perlfaq1-manual, there is the following statement:
>
> "For various reasons, Perl is probably not well-suited for real-time
> embedded systems, low-level operating systems development work like
> device drivers or context-switching code, complex multi-threaded
> shared-memory applications, or extremely large applications."
>
> Unfortunately, the reasons are not explained. I am a PhD-student
> at a research
> group, where parallel processing is a big issue, and I was
> wondering if it
> was possible and feasible to program parallel applications in so called
> scripting languages, perhaps trading development time for
> performance in the
> process. Well, it seems to be possible, as ithreads seem to be
> working. So I
> was wondering, what these unexplained reasons are? Is there a
> document or a
> posting somewhere, that state these explicitly? Or is this just plain old
> information?
>
> Thanks for your help,
> Michael Suess

PerlDiscuss - Perl Newsgroups and mailing lists

2005-06-08, 9:03 pm

du4mi@gmx.de wrote:

Straight from the BUGS section of the threads module POD:
"Creating threads inside BEGIN blocks (or during the compilation phase in
general) does not work. (In Windows, trying to use fork() inside BEGIN
blocks is an equally losing proposition, since it has been implemented in
very much the same way as threads.)"

So, *don't* do this (yet). One good alternative I can think of off the
top of my head to minimize cloned memory is:

use Thread::Use. It's a nice package that allows you control of when
modules are 'require'd & 'import' method is called. In most cases, the
main thread doesn't need all the modules specified, just your worker
threads.

-Eric

> good, I am trying to do this way: creating a worker-thread without modules
> in BEGIN{} block. The problem is how can main programm and this thread
> communicate with each other and share variables, arrays and hashes?
> Using shared variables not working for me. I have something like this:

> BEGIN{
> use strict;
> use threads;
> use threads::shared;
> use warnings;

> threads->new("worker"); #

> sub worker {
> while (1) {
> # do something
> sleep(1);
> }
> }

> }
> use strict;
> use warnings;
> use Win32::Internet; # some modules
> use DBI;
> use Win32::Clipboard;
> use MIME::Base64;
> use Compress::Zlib;
> use Win32;
> use Win32::Sound;
> use Tie::IxHash;
> while(1){
> # do something
> sleep 1;
> }

Sponsored Links