in reply to Re^4: Should I use threads? Perl/DHCP/Radius
in thread Should I use threads? Perl/DHCP/Radius

I am currently figuring out how to synchronize the thread for each MAC with the main thread.

The concept is simple. Have a shared hash or array where each thread can write to a scalar. Have a timer ;-) in the main thread loop thru the hash, and make logical descisions for you.

You have 2 ways of sending messages back from child thread to master thread. One is shared variables, two is thru the fileno's on the open filhandles( which all threads share). You can open a filehandle in the mainthread to listen to with a fileevent method, then have the spawned threads write to that filehandle so that the mainthread can listen for synchronization data.

Also remember to save the tid's ( thread ids) as you spawn them, so your parent thread can join them later, to destroy them. Just Another Hash Problem. ;-) See Reusable threads demo for enlightenment. P.S. Read the replies for a higher level of enlightenment. :-)

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh
  • Comment on Re^5: Should I use threads? Perl/DHCP/Radius

Replies are listed 'Best First'.
Re^6: Should I use threads? Perl/DHCP/Radius
by BrowserUk (Patriarch) on Aug 25, 2010 at 14:38 UTC
    Have a timer ;-) in the main thread loop thru the hash, and make logical descisions for you.

    Simple. And wrong!

    You're still trying to find a way to wield that lumphammer.

    Creating artifical events (polling), is *NEVER* the right approach to solving the problem. Is just spins cycles and wastes resources.

[reply]
      He will want multiple timers checking different things simulanaeously. Without that ability, he eventually will have deeply nested while loops, that clog up and can't be dynamic enough to change every 10 milliseconds. Deeply nested loops are like human insanity.... people claim they are perfectly sane in their unresponsive deeply nested state, whereas the worlds around them are constantly checking and updating their state, pitying the poor deeply nested while loop.... spinning there, stuck, because their code god did not make them with an eventloop, so that they could understand time. bwahaha
      I'm not really a human, but I play one on earth.
      Old Perl Programmer Haiku ................... flash japh
[reply]

        Actually BrowserUk was suggesting threads so that he could avoid those deeply nested loops, synchronization, etc. Each thread can do it's job independently of the others. The main thread would have nothing to do except look for work and spawn new threads as required, and (if required) monitor the currently-existing threads.

        ...roboticus

[reply]
        He will want multiple timers checking different things simulanaeously.

        And that just shows the depth of your misunderstanding.

        Timers do not happen "simulanaeously.". They happen serially. And all on the same thread.

        And if the processing required in response to one of these artificial events takes too long, then you start missing events. So then you have to create more timers and more states and break up the response code into iddy biddy chunks to try and avoid missing events. And then you have to tune those iddy biddy chunks of code each time you move to a different cpu.

        And when your workload increases to the point that your code can no longer keep up with the demand, you move it to new machine with 16 times power; BUT IT DOESN'T HELP ONE JOT!

        It can only utilise 12.5% of your 8-core CPU. Or 6% of your 16-core cpu. or 5% of your 10-core, hyperthreaded cpu.

        Or less than 0.1% of your new 256-core, 1024-thread SMP server.

        Because your single-threaded, event-driven architecture DOESN'T SCALE!

        Your continued attempts to push this ancient, evolutionary dead-end of software architecture, despite that it is so obviously completely unsuited to the realities of modern hardware, is--and I'm sorry to re-use this word, but it is appropriate and measured--asinine.

        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