So, multithreading...
David Frauzel
particular NG, when it could be viewed as more appropriate for a more
generalized compsci NG. It is in relation to a Perl project on which
I'm working, though - and it's a quicky, really, just a quicky. :)
In considering the advantages of multithreading over, say,
multiplexing - should one consider the ability of the target machine
to multithread in a viable fashion?
Here's what I mean:
I'd always thought multithreading really isn't that advantageous to
you unless you have a machine that can handle multiple threads
simultaneously - and by this, I mean SMP - multiple CPUs. When it gets
right down to the level of the CPU, is there any difference between
multithreading and muxing, on a single-CPU machine?
Logan Shaw
David Frauzel <ne...@weathersong.net> wrote:
>I'd always thought multithreading really isn't that advantageous to
>you unless you have a machine that can handle multiple threads
>simultaneously - and by this, I mean SMP - multiple CPUs. When it gets
>right down to the level of the CPU, is there any difference between
>multithreading and muxing, on a single-CPU machine?
If by muxing you mean handling multiple jobs yourself by
manually switching between them (such as by using select()),
then there are two differences that are pretty important:
(1) If you are multiplexing stuff and you make a blocking system
call, then *all* tasks must wait for that call to return.
If you are using threads, then other threads can continue
while you wait on I/O or whatever it is you're waiting on.
(2) Most threads implementations support some form of preemption.
If your work involves interacting with the outside world but also
sometimes doing some heavy computation, using threads can be
helpful because the heavy computation can be put on hold while
you tend to something else. Imagine you have a function foo(),
and it takes 10 seconds for foo() to execute. If you call foo(),
then no other jobs will get serviced until foo() finishes. This
can be bad if you're trying to do something interactive.
To put this another way, threading can do a better job of deciding
_when_ to switch from one job to the next than you're likely to do
if you handle it manually.
There's also the fact that some problems are expressed more easily
in terms of threads. If you have are handling several interactive
sessions or several concurrent web requests, it makes things easier
if you have a thread associated with each session or request.
- Logan
--
"I'll tell you something. Luxury disgusts me." Giorgio Armani, Jan 17, 2002
( http://dailynews.yahoo.com/h/nm/20020117/re/life_fashion_armani_dc_1.html )
David Frauzel
> ...
> There's also the fact that some problems are expressed more easily
> in terms of threads. If you have are handling several interactive
> sessions or several concurrent web requests, it makes things easier
> if you have a thread associated with each session or request.
Wow, that was a very clear explanation, and the reasoning makes
perfect sense. Thanks. :)
Now my (more Perl-related) question becomes: are threads still
unreliable as of 5.6.1? (Specifically ActiveState for Win, if that
makes a difference.) Or is the word still, "Wait for ithreads in 6"?
Uri Guttman
DF> lo...@cs.utexas.edu (Logan Shaw) wrote in message news:<a518eg$bpg$1...@charity.cs.utexas.edu>...
>> ...
>> There's also the fact that some problems are expressed more easily
>> in terms of threads. If you have are handling several interactive
>> sessions or several concurrent web requests, it makes things easier
>> if you have a thread associated with each session or request.
DF> Wow, that was a very clear explanation, and the reasoning makes
DF> perfect sense. Thanks. :)
and you can do any threaded application with multiple processes and
IPC. threads are not some cure all thing. they have their limitations
too. some are small stack sizes as they are allocated with a fixed
size. processes have virtual ram for a stack so they can
grow. synchronizing threads can be a pain. interlocks too.
you can run processes under event driven multiplexors and get all the
advantages of threads with few of the problems. stem does just that for
you.
i am not saying threads don't have their uses but to say they are always
better than anything else is misleading. many things are harder in
threads because of the shared space and locking issues. cooperative
multitasking (event driven) has no locks or sync issues. i/o is easier
to share. managing processes is easier too.
just my view. i have been hacking event systems for a long time.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Randal L. Schwartz
Logan> There's also the fact that some problems are expressed more easily
Logan> in terms of threads. If you have are handling several interactive
Logan> sessions or several concurrent web requests, it makes things easier
Logan> if you have a thread associated with each session or request.
As long as you also add that in Unix, thread is most reliably spelled
"f o r k", I'll agree.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Edwin Günthner
Uri Guttman wrote:
> grow. synchronizing threads can be a pain. interlocks too.
What is the difference between the synchronizing threads and processes?
If you do it wrong, you end up in deadlocks. I cant see that it
makes a difference if two threads or two processes are "deadlocked".
Maybe I miss the point, but if A has to wait becauses it needs something
from B - why does it make a difference if A and B are threads or
if they are processes?
Uri Guttman
EG> Uri Guttman wrote:
>> grow. synchronizing threads can be a pain. interlocks too.
EG> What is the difference between the synchronizing threads and
EG> processes? If you do it wrong, you end up in deadlocks. I cant
EG> see that it makes a difference if two threads or two processes are
EG> "deadlocked".
you can manage IPC with pipes and sockets and control deadlock that
way. and deadlock isn't the issue, but synchronizing is. threads need a
way to communicate with each other and that is usually through shared
memory and locks. so threads may have to lock in many places and either
spin (sucks) or block and either way that thread isn't doing any work.
EG> Maybe I miss the point, but if A has to wait becauses it needs
EG> something from B - why does it make a difference if A and B are
EG> threads or if they are processes?
because with processes you can block on a pipe in an IPC setup and the
manager process won't have to block or spin lock. it can use an event
loop to manage them. there is no event setup for mutexes in general so
you have a different control structure. you can solve problems either
way but i find events more natural to me than threads and less
limiting. they do require a different way to think about things such as
state, communication, etc. most people seen to grasp threads easier. but
i think events has more flexibility. you can actually use both in a
process as i have.
Benjamin Goldberg
You can fork() reliably in 5.6.1, and *should* be able to use threads
reliably in 5.8 (coming in May! I think it's May, anyway...). If
you're wondering how stable the threads for 5.8 will be, you can
download 5.7.2, and try using them: what you see is pretty close to what
you will get.
--
print reverse( ",rekcah", " lreP", " rehtona", " tsuJ" )."\n";
Benjamin Goldberg
Sure! Using multiple threads or multiple processes can make your code
much simpler.
Consider the difference between these two echo servers:
$SIG{CHLD} = sub { wait };
while( 1 ) {
my $client = $socket->accept() or warn("accept: $!"), next;
fork and next;
print $client $_ while sysread $client, $_, 4096;
exit;
}
Versus:
my $sel = IO::Select->new($socket);
while( 1 ) {
my @ready = $sel->can_read() or warn("select: $!"), next;
my @clients = grep { $_ != $socket } @ready;
if( @clients != @ready ) {
if( my $client = $socket->accept() ) {
$sel->add($client);
} else { warn "accept: $!" }
}
foreach my $client ( @clients ) {
if( sysread($client, $_, 4096) ) {
print $client $_;
} else { $sel->remove($client) }
}
}
See how much much simpler the one which uses multiple processes is?