I'm gonna pick out two paragraphs from your write-up on PSiCHE, that I think states one of the limitations of iThreads infinitely more clearly than I've ever been able to say it, or any other desceription I've ever read.

Within Perl's current ithreads implementation, variables are private to each thread, and each newly created thread gets a private copy of each existing variable. All of which may seem reasonable...until your threads need to share information. Enter threads::shared, which defines a simple interface to declare a variable as "shared".

Unfortunately, threads::shared imposes a significant burden: since all threads::shared variables are managed within a single shared Perl interpretter context, a single global lock on that context must be acquired before any thread can do anything to any thread::shared variable. No matter if each thread is referencing completely different variables, and is only doing read operations, they all must first exclusively acquire the global lock before accessing the shared variables (Frankly, it calls into question the point of providing application-level locking primitives). The problem is exacerbated by the frequent reference count adjustments applied to the shared variables as various threads create and destroy proxy versions and references.

Maybe, if any of the people that count have been following along on my recent crusade on the future of threads, and are still paying some attention, this might do some good.

I'm particularly taken by the emboldened sentence (my emphasis), as oft times, when I've attempted to detect race conditions on my single cpu system by omitting user locking, I've failed. My code has been 'accidentaly protected' by the locking Perl uses to protect it's internals. This has caused me to question the need for user locking on single cpu systems on several occasions.

Of course, ikegami's recent tutorial builds on Dave_the_m's earlier elegantly simple and informative, but easily missed or forgotten answer, to confirm that user locks are needed.

(Ps. I've looked for a way to replace threads::shared for ages, but it looks like you have something that really might fly. Keep up the great work!)