Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

multi threading

by mude (Novice)
on Feb 29, 2008 at 03:46 UTC ( #671087=perlquestion: print w/replies, xml ) Need Help??
mude has asked for the wisdom of the Perl Monks concerning the following question:

hi guys.. im totally new with perl and was given an urgent task to make a multi-threading perl script...

i need to create multiple number of threads out of one... and fire them all up at once. i need to get the timing to make sure if all the process started simultaneously.

i came up with a module "Thread::Barrier" but, i don't have enough resources on how to use it.... been googling this module lately but i haven't seen anyone using it... i couldn't clearly understand the examples shown in this module...

for sure i used it in a wrong way...

1. create multiple number of threads (user input) out of 1.
2. fire them all up at once..
3. get the timing to prove that these threads are all executed at the same time.

i tried making a script.... with just simple print as a process.... and i also used system "date" to check if the processes were executed at the same time....

can lead me to the right path guys... thanks
#!/usr/bin/perl use warnings; use threads; use threads::shared; use Thread::Barrier; my $br = Thread::Barrier->new; my $thr1 = threads->new(\&req); $thr1->join; sub req { $count=0; print "Enter number: "; $num = <STDIN>; my @thrlist; for (1..$num) #create number of threads { $thrlist[$_] = threads->new(sub { print"test\n"; syste +m("date"); }); $thrlist[$_]->join; $count++; } foreach (threads->list){ $br->wait; } print $br->wait; print "\n\ntotal number of threads $count\n\n"; }

Replies are listed 'Best First'.
Re: multi threading
by plobsing (Friar) on Feb 29, 2008 at 05:36 UTC
    How good is simultaneously? Within a second of each other? It is unreasonable to expect they all start during the same CPU cycle.

    Thread::Barrier looks like as good a tool for the job as any. However, in my experience, getting deterministic behaviour out of threads is like herding cats.

    To finely test timing details, I would recommend you look at the Time::HiRes module.

      simultaneously at once..... same time of execution.... some kinda synchronized processing.........

        A single CPU can only execute one piece of code at a time. No matter how many threads or processes you use, only one will be doing anything at any given moment. It is only the ability of the OS to switch between different threads/processes at relatively high speeds that give the impression of many things are happening at once.

        If your machine has 2 processors, then 2 threads can be doing something at exactly the same time. But, if your process has two threads, it is very unlikely that each of those threads would be running on a separate processor at exactly the same moment. This is because your process threads have to compete with the threads of every other process running on that machine. And most OSs have anything from a few tens to several hundred threads running in 'system processes'. Ie. those programs and drivers that make up the OS itself that you have no control over.

        So, even if your machine has one processor per thread you intend to run, expecting to get even two threads to run "simultaneously" is impractical, if not impossible.

        The best you could hope to achieve is to arrange for your threads to become eligible to run at the same moment using the cond_wait()/cond_signal()/cond_broadcast() APIs documented in threads::shared, and then allow the scheduler to run them as close together as it can. But you will probably need to acquire considerably more understanding of Perl and threads before you will be able to achieve optimum results. And even then, they will still not be running "simultaneously".

        The best you will be able to achieve is number of threads * task-switch-time / number of CPUs. You'll have identical or worse results using processes.

        Or, you could try describing what you are actually trying to achieve with your program, and perhaps someone can suggest a practical alternative.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: multi threading
by stiller (Friar) on Feb 29, 2008 at 05:56 UTC
    Hi, I haven't used Thread::Barrier myself, but from its description (on CPAN) it is not the right module for your usage here. It's for letting a bunch of threads start doing their things when some resource is ready, and to wait for each other to complete before advancing to the next workpice coming in.

    You will need to read up on threads in general. You will probably not need anything more esoteric than threads. You might also look at fork, if parallellism is the point, and not threads per se.

Re: multi threading
by tirwhan (Abbot) on Feb 29, 2008 at 11:06 UTC

    Time to bring out one of my favourite computing quotes once again (and it's more applicable than the last time I did :-):

    A computer is a state machine. Threads are for people who can't program state machines. - Alan Cox

    Processors handle commands sequentially, it is impossible for any currently existing CPU core to handle two instructions at the same time (well, this is not strictly true for SMT processors, but things get hairy enough here to ignore that for this discussion). Thus, the number of operations that can theoretically be executed at exactly the same time on your machine will be limited by the number of CPU cores on that same machine. Even then, synchronising several processes to execute exactly the same command at the same time on different cores is a hard task and likely not possible without reaching into your OS kernel (in fact, I'd be surprised if it were possible on a non-RT OS at all). Now, if (as indicated in your post) you are using "date" to confirm the processes are running at the same time this probably means you don't actually need them to run at the exact same microsecond but have a certain leeway. You'd need to tell us what you're actually trying to do and what kind of delay in execution is acceptable before we can make any sensible suggestions. If, for example, the task is non-blocking (i.e. does not involve IO) and quick, simple sequential processing in a loop may be sufficient.

    All dogma is stupid.

      as i wrote above... thats what im tryin to accomplish.....

      many thanks....
Re: multi threading
by Joost (Canon) on Feb 29, 2008 at 10:47 UTC
    i need to create multiple number of threads out of one... and fire them all up at once. i need to get the timing to make sure if all the process started simultaneously.
    Threads do not work that way, can't work that way and should not work that way.

    If your program depends on threads all staying synchronized then at best your program is going to be much more complex and slow than you probably need, and at worst you'll never get it to work reliably.

    We may be able to help you if you explain why you think you need this kind of synchronization.

      as my reply to BrowserUK....
      im trying to test a dhcp server.... sending massive
      resquest and simultaneous if possible.. but since its
      not... then i guess ill just try to make my script fast
      and efficient...

      once again... thank you very much for your replies...
        Well, there may be some value in using threads (or fork) here, but you will probably have to focus on making your code efficient to make it work well.

        If I were you I'd run a fairly small bunch of concurrent processes or threads (not a lot more than you have CPUs in your target machine) that would each do asynchronous DHCP requests (in other words, have each thread initiate a lot of requests, and handle the responses as they come in, instead of waiting for the response before doing the next request).

        An event handling system is going to be much more efficient than threads for this kind of problem, and the only reason you really want to use threads or fork is to spread the load better over multiple processors (though you may not even need to).

Re: multi threading
by renodino (Curate) on Feb 29, 2008 at 16:16 UTC
    some kinda synchronized processing

    Er...threads have enough problems with non-deterministic behavior, you might want to refine that "requirement" a bit ?

    And I spotted a rather gruesome wart in the midst of your example: invoking

    from inside a thread is not exactly best practice (you do realize system() turns into a fork()?). Consider using
    print "test\n", scalar localtime(), "\n";

    Of course, making that edit changes the whole behavior of the threads: since its much faster, many threads will complete before other threads have even been its not exactly simultaneous.

    As BrowserUk mentioned, look into lock() and cond_wait().

    Perl Contrarian & SQL fanboy

      thank you... ill change it.....

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://671087]
Approved by ikegami
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (7)
As of 2017-09-21 19:50 GMT
Find Nodes?
    Voting Booth?
    During the recent solar eclipse, I:

    Results (252 votes). Check out past polls.