in reply to Re^2: thread/fork boss/worker framework recommendation
in thread thread/fork boss/worker framework recommendation

it is too large to share in mass via this site.

I do have email... but if you can't show me, I cannot help.

From a program architecture standpoint, I am having to do a lot of low level thread and thread pool management in my code. As I progressed from writing the first job step to the 7th, I have developed a module that encapsulates this pattern; however, it isn't work that I am proud of or want to support. I have been through a number of thread pool management modules on CPAN. Most simply don't work, don't fully work, or don't work well with the current versions of perl.

Re: The highlighted portion. This is a myth! (Or simply beginners coding.)

Thread pool management only becomes complex or laborious when people insist on trying to wrap it up in an API. It is the very process of that wrapping that creates complexity. There are so many ways to use thread pools, that writing a wrapper has to deal with so many possibilities that it just creates complexity everywhere. Which is why I don't use such modules.

Written the right way, thread pools don't need to be 'managed', they manage themselves. Here is a complete working example in 30 lines, some of which are just for show. I've typed it so many times now, I can do it from memory, and get it right first time, every time:

#! perl -slw
use strict;
use Time::HiRes qw[ time ];
use threads;
use Thread::Queue;

sub worker {
    my $tid = threads->tid;
    print "Thread: $tid started";
    my $Q = shift;
    while( my $workitem = $Q->dequeue ) {
        print "Thread: $tid processing workitem $workitem";
        sleep $workitem;
    }
    print "Thread: $tid ended";
}

our $WORKERS //= 10;
our $ITEMS   //= 1000;
our $MAXWORK //= 2;

my $Q = new Thread::Queue;
my @workers = map threads->create( \&worker, $Q ), 1 .. $WORKERS;

for ( 1 .. $ITEMS ) {
    sleep 1 while $Q->pending > $WORKERS;
    $Q->enqueue( rand( $MAXWORK ) );
    print "main Q'd workitem $_";
}
print "Main: telling threads to die";
$Q->enqueue( (undef) x $WORKERS );

print "Main waiting for threads to die";
$_->join for @workers;

[download]

A run:

[16:03:44.95] c:\test>ThreadPoolExample -WORKERS=4 -ITEMS=20 -MAXWORK=
+1
Thread: 1 started
Thread: 2 started
Thread: 3 started
main Q'd workitem 1
main Q'd workitem 2
main Q'd workitem 3
main Q'd workitem 4
main Q'd workitem 5
main Q'd workitem 6
main Q'd workitem 7
main Q'd workitem 8
Thread: 2 processing workitem 0.170745849609375
Thread: 1 processing workitem 0.852569580078125
Thread: 1 processing workitem 0.3243408203125
Thread: 1 processing workitem 0.4161376953125
Thread: 1 processing workitem 0.034759521484375
Thread: 1 processing workitem 0.488800048828125
Thread: 4 started
Thread: 3 processing workitem 0.927337646484375
Thread: 2 processing workitem 0.23193359375
main Q'd workitem 9
main Q'd workitem 10
main Q'd workitem 11
main Q'd workitem 12
main Q'd workitem 13
main Q'd workitem 14
main Q'd workitem 15
main Q'd workitem 16
main Q'd workitem 17
Thread: 3 processing workitem 0.3211669921875
Thread: 3 processing workitem 0.806793212890625
Thread: 3 processing workitem 0.1046142578125
Thread: 3 processing workitem 0.812042236328125
Thread: 3 processing workitem 0.38275146484375
Thread: 3 processing workitem 0.60479736328125
Thread: 1 processing workitem 0.225616455078125
Thread: 2 processing workitem 0.750457763671875
Thread: 4 processing workitem 0.132110595703125
main Q'd workitem 18
main Q'd workitem 19
main Q'd workitem 20
Main: telling threads to die
Main waiting for threads to die
Thread: 2 processing workitem 0.96856689453125
Thread: 2 ended
Thread: 3 processing workitem 0.59661865234375
Thread: 3 ended
Thread: 1 processing workitem 0.765777587890625
Thread: 1 ended
Thread: 4 ended

[download]
I think I have come up with an approach

Okay, it looks like you are decided and there's nothing left for me to try and help you with. Good luck.

I'll finish by saying this though. I bet that if you'd give me the specs for your problem so that I could write the thread-pool version, it would be quicker and simpler to write, easier to maintain, and scale better than your event-driven approach.

(That's a bold claim given I have no knowledge of what your code does. But hey, you gotta live a little :)

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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.

The start of some sanity?

Replies are listed 'Best First'.
Re^4: thread/fork boss/worker framework recommendation
by learnedbyerror (Monk) on Dec 01, 2011 at 17:18 UTC

    I wouldn't consider myself a beginner with threads and neither would I consider myself an expert, journeyman is probably about right. But, I do have about 35 years of experience with a multitude of different languages and have learned a few things that are true of every one of them. #1 - the less repetitive typing used the fewer the bugs, and #2 - I would rather stand on the shoulders of giants by using their knowledge than become a giant on my own.

    Though I have been coding perl since version 2, I don't use it every day and things get rusty at times. Furthermore, though Perl5 has been around for a while, there are a lot of new and exciting things going on in it. I don't want to constrain myself to just what I have learned/done in the past. I don't discount that what I know will work, I just try to take a look around when tackling something new to see if there is a better mouse trap available.

    In general, I like the current thread model in perl (post 5.8), and I use quite regularly in small stuff that comes and goes. I hope that future improvements will reduce its overhead, reduce the complexity of threads::shared for complex data structures in references, and possibly even provide an OO interface.

    For whatever reasons, possibly intangible, I don'think threading is the right approach for this current project, hence my investigation of alternatives. As I refactor my work to date, I'll break up some of the larger chunks of code into a more modular approach. Afterwards, I'll be in a position to be able to efficiently try several different multi-threading/processing approaches and see how they work. If I find anything interesting, I'll stick it out here.

    Thanks again for your opinions

    lbe

[reply]
      I wouldn't consider myself a beginner with threads and neither would I consider myself an expert, journeyman is probably about right. But, I do have about 35 years of experience with a multitude of different languages and have learned a few things that are true of every one of them. #1 - the less repetitive typing used the fewer the bugs, and #2 - I would rather stand on the shoulders of giants by using their knowledge than become a giant on my own.

      That paragraph brings two thoughts to mind.

      1. The iThreads model used by Perl/threads.pm is quite different from every other threading model I've used going back the best part of 30 years.

        As a bolt-on after-the-fact addition to Perl, it has its limitations and peculiarities. It can be really quite effective for many types of concurrent algorithms, but does require that you are aware of it quirks in order to get the best from it.

        The approach it requires for many problems is often quite different from other threading models.

      2. The problem with most (actually all those i've tried) of the thread pooling modules on CPAN is that they haven't been written by giants.

        For the most part they've been written as a first attempt by people for whom iThreads is their first real experience of threading of any form, and based upon very dubious analogies.

        They are over-complex, badly tested and often written in isolation of any real application. Hence they may seem to run for some purely demonstration application, but fall in a heap when you try to use them for anything remotely practical.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      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.

      The start of some sanity?
[reply]

        I don't know the authors, so I can't say they aren't giants. Some were written by people who have some respected modules behind them. What I can say, is that none of the thread pool modules came close to meeting my, what I think to be a relatively common and simple, need.

        The same can be said for many of the similar modules for forks.

        Many of the thread and fork modules are old and fail installs or install with insufficient testing to identify problems with running under new versions of perl. The good and the bad of CPAN is that you get to see everything. It would be great to be able to select some filter, like known to work on 5.10 and greater, or actively maintained. I think that would focus people in on modules that are reasonable for consideration.

        lbe

[reply]

In Section Seekers of Perl Wisdom