in reply to multi threading

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.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Replies are listed 'Best First'.
Re^2: multi threading
by mude (Novice) on Mar 01, 2008 at 10:55 UTC

    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...
[reply]
      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).

      "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]

        Unless the machine has multiple interface cards, there is very little if any benefit in using multiple threads or processes, or an event driven architecture, as regardless of the presence of multiple cpus, all the outbound packets will be serialised at the interface card.

        He might as well just run a tight loop issuing requests as fast as the processor/interface can send them.

        As UDP is connectionless, at most, he might benefit from two threads/processes per cpu. One to send as fast as possible and another to receive replies assuming he is going to bother.

        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.
[reply]

In Section Seekers of Perl Wisdom