Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > MultiThreading and 'fork'

Reply
Thread Tools

MultiThreading and 'fork'

 
 
Naveen Reddy
Guest
Posts: n/a
 
      01-25-2004
Hello all,
From my Perl program I can spawn a parent and a child process using
the 'fork'.
Is this synonymous to 'multi-threading' and are the 'threads' same as
'processes'?

I'm trying to understand why theres a module for threads, as in, 'use
threads', when fork lets you accomplish the mutiltasking?

Thanks for your time,
Reddy
 
Reply With Quote
 
 
 
 
Ben Morrow
Guest
Posts: n/a
 
      01-25-2004

http://www.velocityreviews.com/forums/(E-Mail Removed) (Naveen Reddy) wrote:
> Hello all,
> From my Perl program I can spawn a parent and a child process using
> the 'fork'.
> Is this synonymous to 'multi-threading' and are the 'threads' same as
> 'processes'?


No. Have you read perlthrtut?

> I'm trying to understand why theres a module for threads, as in, 'use
> threads', when fork lets you accomplish the mutiltasking?


Threads are lighter than processes (creating many threads consumes
fewer resources than creating many processes), and it is possible to
share variables among threads. In theory all data is shared, but
perl's ithreads copy all the perl data structures when you create a
new thread, except those that are marked shared.

I would say that there is a good case for considering ithreads to be
pretty much redundant with fork() and threads::shared with Sys::Mmap
or some such, but those concepts are not portable outside unix whereas
ithreads are.

Ben

--
Joy and Woe are woven fine,
A Clothing for the Soul divine William Blake
Under every grief and pine 'Auguries of Innocence'
Runs a joy with silken twine. (E-Mail Removed)
 
Reply With Quote
 
 
 
 
Chris Mattern
Guest
Posts: n/a
 
      01-25-2004
Naveen Reddy wrote:
> Hello all,
> From my Perl program I can spawn a parent and a child process using
> the 'fork'.


Well, you can spawn a child process. The parent was there to begin
with.

> Is this synonymous to 'multi-threading' and are the 'threads' same as
> 'processes'?


No. Threads share the same address space.

>
> I'm trying to understand why theres a module for threads, as in, 'use
> threads', when fork lets you accomplish the mutiltasking?


Because fork() has much higher overhead and processes have more
difficulty passing information back and forth.

Chris Mattern

 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      01-25-2004
In article <(E-Mail Removed)>, Chris Mattern <(E-Mail Removed)> wrote:
:Naveen Reddy wrote:
:> I'm trying to understand why theres a module for threads, as in, 'use
:> threads', when fork lets you accomplish the mutiltasking?

:Because fork() has much higher overhead and processes have more
:difficulty passing information back and forth.

fork() on modern Unix systems does not necessarily
have more overhead than perl 5.8.2 ithreads .

Many modern unix servers have hardware-supported "copy-on-write"
semantics -- all they have to to is sweep through the existing process
page descriptor table, set the COW bit, and copy the resulting page
descriptor table into the new process.

The current implimentation (5.8.2) of ithreads involves process-level
copying of all existing perl variables that are not marked as shared.
If one has much data at all, that procedure is going to take longer
than the process creation overhead.

In a multi-threaded process I was recently working on, it took
about (roughly) 2 seconds per ithread spawned, whereas fork()'s
take a fraction of a second each.
--
Will you ask your master if he wants to join my court at Camelot?!
 
Reply With Quote
 
Ilya Zakharevich
Guest
Posts: n/a
 
      01-26-2004
[A complimentary Cc of this posting was sent to
Chris Mattern
<(E-Mail Removed)>], who wrote in article <(E-Mail Removed)>:
> Because fork() has much higher overhead and processes have more
> difficulty passing information back and forth.


Starting from v5.8, perl (by default) does not support threads any
more. v5.9 has no thread support at all.

What v5.8 supports is "emulation of fork() on Win32 systems". This
emulation layer was hacked to implement creation of a "thread +
cloned-interpreter" pair. Creation of such a pair (via the
fork()-emulation layer!) is (in my measurements) 2 orders of magnitude
slower that creation of a new child process.

Hope this helps,
Ilya
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      01-26-2004
In article <bv1m6b$1e0t$(E-Mail Removed)>,
Ilya Zakharevich <(E-Mail Removed)> wrote:
:Starting from v5.8, perl (by default) does not support threads any
:more. v5.9 has no thread support at all.

Perhaps that needs to be qualified with "ActiveState"? Or are
you referring to 5005 threads as compared to ithreads ??
--
csh is bad drugs.
 
Reply With Quote
 
Ben Morrow
Guest
Posts: n/a
 
      01-26-2004

http://www.velocityreviews.com/forums/(E-Mail Removed)-cnrc.gc.ca (Walter Roberson) wrote:
> In article <bv1m6b$1e0t$(E-Mail Removed)>,
> Ilya Zakharevich <(E-Mail Removed)> wrote:
> :Starting from v5.8, perl (by default) does not support threads any
> :more. v5.9 has no thread support at all.
>
> Perhaps that needs to be qualified with "ActiveState"? Or are
> you referring to 5005 threads as compared to ithreads ??


Of course he is. Given Ilya's previous posts of the evils of fork(),
it is unsurprising he dislikes ithreads. I have to admit, it seems
rather daft to attempt to reimplement in perl something which the OS
does perfectly well; except on those OSen which don't. I have serious
doubts that ithread creation will ever become less expensive than
process creation on a decent unix, simply because they are essentially
the same operation.

Ben

--
Joy and Woe are woven fine,
A Clothing for the Soul divine William Blake
Under every grief and pine 'Auguries of Innocence'
Runs a joy with silken twine. (E-Mail Removed)
 
Reply With Quote
 
Ilya Zakharevich
Guest
Posts: n/a
 
      01-26-2004
[A complimentary Cc of this posting was sent to
Ben Morrow
<(E-Mail Removed)>], who wrote in article <bv1pns$da$(E-Mail Removed)>:
> > Perhaps that needs to be qualified with "ActiveState"? Or are
> > you referring to 5005 threads as compared to ithreads ??

>
> Of course he is. Given Ilya's previous posts of the evils of fork(),
> it is unsurprising he dislikes ithreads.


Myself, I do not see any connection between these two acts of madness.
Introducing fork() *was* an act of madness in '70; however, today,
when (on Unix) most problems associated with this madness are either
already resolved, or at least well understood, most it deserves is
just a shrug. [Of course, outside of Unix it provides enormous
difficulties to developers, but for the purpose of simiplicity, I
would like to keep the discussion of ithreads focused on one
architecture only.]

The fact that "fork() emulation on Win32" is related to fork() has
little to do with the problem of ithreads. Consider the code to
perform emulation as a black box. It is just a subsystem of Perl
which does "something".

Now somebody got a bright idea: "running this subsystem on Unix will
give us an interpreter running in a new thread; code reuse is a good
thing; let us just use this subsystem to create new threads."

"BTW, a lot of people had problems with running the old model of
threads. We care; let us remove the support for the old model, so
people do not have these problems."

Now we got a system which uses a microscope to pull nails. The
microscope does not care, but the finishing is all ruined.

> I have to admit, it seems rather daft to attempt to reimplement in
> perl something which the OS does perfectly well; except on those
> OSen which don't. I have serious doubts that ithread creation will
> ever become less expensive than process creation on a decent unix,
> simply because they are essentially the same operation.


Are you joking? Did you read the code for fork() emulation? Did you
run any benchmarks? The code is 2 orders of magnitude slower than
process creation.

Try to create 20 ithreads/sec; it may be possible on very recent
hardware, but I think it is close to the current maximum...

Hope this helps,
Ilya
 
Reply With Quote
 
Ben Morrow
Guest
Posts: n/a
 
      01-26-2004

Ilya Zakharevich <(E-Mail Removed)> wrote:
> [A complimentary Cc of this posting was sent to
> Ben Morrow
> <(E-Mail Removed)>], who wrote in article <bv1pns$da$(E-Mail Removed)>:
> > I have to admit, it seems rather daft to attempt to reimplement in
> > perl something which the OS does perfectly well; except on those
> > OSen which don't. I have serious doubts that ithread creation will
> > ever become less expensive than process creation on a decent unix,
> > simply because they are essentially the same operation.

>
> Are you joking? Did you read the code for fork() emulation? Did you
> run any benchmarks? The code is 2 orders of magnitude slower than
> process creation.


I think you must have misread me. I said that not only is ithread
creation *currently* slower than process creation, but also there are
good reasons for thinking that on a unix system it will *always* be
slower, no matter how much p5p optimize it; namely, that it is
emulating in userland something already implemented perfectly well in
the kernel.

Ben

--
don't get my sympathy hanging out the 15th floor. you've changed the locks 3
times, he still comes reeling though the door, and soon he'll get to you, teach
you how to get to purest hell. you do it to yourself and that's what really
hurts is you do it to yourself just you, you and noone else * (E-Mail Removed)
 
Reply With Quote
 
Ilya Zakharevich
Guest
Posts: n/a
 
      01-27-2004
[A complimentary Cc of this posting was sent to
Ben Morrow
<(E-Mail Removed)>], who wrote in article <bv3tag$gv1$(E-Mail Removed)>:
> > Are you joking? Did you read the code for fork() emulation? Did you
> > run any benchmarks? The code is 2 orders of magnitude slower than
> > process creation.


> I think you must have misread me. I said that not only is ithread
> creation *currently* slower than process creation, but also there are
> good reasons for thinking that on a unix system it will *always* be
> slower, no matter how much p5p optimize it; namely, that it is
> emulating in userland something already implemented perfectly well in
> the kernel.


Still: I do not consider your disclaimer sufficient. The overhead of
creation of a *thread* should/could be orders of magnitude smaller
than the overhead of creation of a new process.

However, the overhead of creation of a *new interpreter* is very large.
And the overhead of *cloning* an interpreter (as opposed to creating a
new one) is jet orders of magnitude larger.

Hope this helps,
Ilya
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Web Garden and multithreading query techie ASP .Net 9 09-06-2005 08:43 PM
HttpModule multithreading and request and response corelation =?Utf-8?B?U2hhcGlybw==?= ASP .Net 7 12-08-2004 01:41 PM
Multithreading and Sessions Imran ASP .Net 1 01-28-2004 02:24 AM
Session State does not Work with Multithreading and SQL Server - Bug??? Ilia ASP .Net 6 11-04-2003 03:55 PM
multithreading and member-functions Ilia Poliakov C++ 16 09-05-2003 08:42 AM



Advertisments