Also in the model that u have proposed how do i add support for handling multiple queries,i can use the same strategy as i had used before...

Yes. Second and subsequent queries to the same client will just get picked up by the next available worker.

However, if it is important to only issue a single query against a given client at any one time, you'd have to take additional steps to ensure that. If that is the case, speak up and I'll see what I can come up with.

A few comments on your code:

1. I generally prefer to start the workers, before adding the work items to the queue.

   More habit than for any reason I can remember, but the workers will just block on the queue until there is something to do anyway. And I have vague recollections of it making a difference on at least one occasion.

2. There is no real benefit to using a hash to store your thread handles.

   An array is simpler and works better.

3. There is no need to pass an integer to each thread as an identifier.

   You can obtain the process unique thread id using:

   my $tid = threads->self->tid;
   [download]

   Where threads->self is a class method that returns the thread handle of teh current thread and ->tid is an instance method that return the thread identifier for the invocant thread handle.

4. undef is an intrinsic value (Not a string as you have it).

   And whilst you were only starting a single thread for now, it better to use the configuration variable $maxnoofThreads to ensure sufficient undefs are stacked to terminate all the threads.

   The construct:

   $q->enqueue( ( undef ) x $maxnoofThreads );
   [download]

   Says: build a list of $maxnoofThreads undefs and push them onto the queue.

5. As you only put the handles of the worker threads into the list, there is no need to check whether one of them is the main thread.
6. There is no need to return unless $workitem.

   Once all the work items have been processed, each thread will dequeue an undef, and the while loop will terminate naturally. and the thread will terminate when it "falls of the end" of the worker sub.

7. And time you use a shared resource (like printing to the terminal or a file), from multiple threads, you should serialise acccess to that resource.

   Ie. Apply locking to a shared variable.

   On some systems, printing to the screen will be serialised by the OS or runtime, but you cannot rely on that everywhere. Also, if the output is redirected to a file, the automatic serialisation goes away.

Putting that all together, it looks like this:

use strict;
use threads;
use threads::shared;
use Thread::Queue;

my $mtxStdOut : shared;
my $maxnoofThreads = 1;

my @clientList =  qw(
    client1 client2 client3 client4 client5 client6
    client7 client8 client9 client10 client11 client12
);

my $q = new Thread::Queue;

my @workers = map {
    threads->new( \&worker, $q );
} 1 .. $maxnoofThreads;

$q->enqueue(@clientList);
$q->enqueue( ( undef ) x $maxnoofThreads );

$_->join for @workers;

sub worker {
    my( $Q ) = shift;
    my $tid = threads->self->tid;
    while( my $workItem = $Q->dequeue ) {
        {
            lock $mtxStdOut;
            print " workitem  from thread $tid -->$workItem\n";
        }
        ## Perform query
        ## Perform comparison
        ## Perform output/cleanup
    }
}
[download]

That's a very lightly customised template that I use for most threaded perl applications. It's flexible enough that it lends itself to many uses and is tested well enough that it just works in most cases.