There are a lot of "anomolies" in your script.

The primary cause of the errors you are complaining of is becasue you are using a global variable (despite the my applied to it's declaration) to store your thread handles.

This my @threadList = (); declares the array, but this array is then reused over and over within a subroutine, within nested loops:

sub runTests
{
...
    foreach my $userType (...
        for my $i ( ...
            push @threadList, threads->new( ...
        }
    }
...
   foreach my $thread (...
        $thread->join;
   }
}
[download]

So, each time through, you are pushing thread handles into that array, and then later joining them--but you never remove them!

Which means that the second time through, you still have all the (joined) thread handles from the first run, and you attempt to re-join these, and get errors.

A few others:

sort { $allScripts{$a} <=> $allScripts{$b} } keys %allScripts
[download]

The keys to this hash are strings, but you are using the numeric comparator (<=>), which means you are also getting a load of Argument "..." isn't numeric in numeric comparison (<=>) at... which you are apparently ignoring.

Your comment:

    # key-value pairs in a Perl hash are not always 
    # stored in the order in which they were defined!
[download]

is very misleading--mostly because it is so nearly true :) The order in which keys are returned by the keys operator is "Not well defined". In versions prior to 5.8.something, the order was determined by a series of internal storage details that means it was "essentially random". In later versions, the return order is deliberately randomised for security reasons, so it is "actually random".

If it is important to your application that you can iterate your data structure in a specific order, you should either use an array -or- one of the many "sorted hash" modules from CPAN.

Finally, I'm not sure what your script is trying to achieve, so this comment may be way off base, but in general, "threads" and "timing" do not go together.

Threads are non-determanistic, which is to say, the time between your program asking a thread to start, and that thread actually getting a timeslice and running is determined by the OS according to a variety of factors that are entirely beyond prediction--system load, number of cpu's, whether other threads and processes in the system are cpu-bound or IO-bound; and a whole host of other factors.

Timing things that are running on concurrent threads is about as meaningful as a chocolate teapot.