I see darrellb has answered your question, but it might be worth pointing out that if you benchmark Thread::Queue without loading threads, you are not going to get very useful results. Without threads loaded, when T::Q tries to load threads::shared to gain access to share, lock and the cond_* functions, the use threads::shared; becomes a noop. Hence, you will be benchmarking a normal perl array via a (somewhat slower) OO interface.

The difference in timings between push/pop with and without threads loaded is quite marked:

Without:

Benchmark:
timing 1000000 iterations of
 a_push, b_pop
...

    a_push:  4 wallclock secs ( 3.31 usr +  0.08 sys =  3.39 CPU) @ 29
+4898.26/s (n=1000000)

     b_pop:  4 wallclock secs ( 3.91 usr +  0.00 sys =  3.91 CPU) @ 25
+6016.39/s (n=1000000)
[download]

With:

[ 2:13:30.98] P:\test>junk
Benchmark:
timing 1000000 iterations of
 a_push, b_pop
...

    a_push: 19 wallclock secs (16.02 usr +  3.53 sys = 19.55 CPU) @ 51
+161.36/s (n=1000000)

     b_pop: 21 wallclock secs (17.52 usr +  2.34 sys = 19.86 CPU) @ 50
+352.47/s (n=1000000)
[download]

The slowdown when locking and sharing are active is to be expected, and is unlikely to be too much of a concern in a threaded application, and there is little point in using T::Q in a non-threaded application.