I was impressed with: Perl Scalable ithreaded Component Helper Extensions

FWIW: I'm not 'turfing here...I don't know Zukoff, but his/her post is somewhat timely, so I'll bite...

Be advised that PSiCHE is very much a work in progress. Tho I have successfully applied the techniques for a couple major projects, those efforts have exposed some issues which I'm trying to address (even as I post).

First up is the dead whale beached in the middle of threads::shared (aka the shared interpretter context lock). Thread::Sociable is progressing, but its going to take awhile before its ready for prime time. However, its already showing promise: thus far, a minimum 2x faster for simple single threaded reads, 3x for writes...and when thread counts hit 20+, Sociable really starts to shine.

Devel::Psichedb is likewise a work in progress, and probably essential to developing large scale PSiCHE solutions, given the limited (non-existant?) support I've encountered thus far for multithreaded/multiprocess-friendly debugger interfaces.

So while I'm happy you've expressed interest, and hope you'll give (e.g.) Thread::Apartment a spin, be aware there will be dragons.

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!)

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.