While tying up loose ends on Thread::Sociable, I happened to be reviewing a few STM research papers. Thus far, they've confirmed my skepticism: performance sucks until about 8+ CPUs (yes, thats hardware, *not* processes, and not threads).
But Sociable had so much of the scaffolding just sitting there. Hence, I couldn't silence the persistent nagging voice in the back of my head. So I've taken up the challenge of adding STM to Sociable.
On the plus side, it turns out the runtime overhead for transactional variables shouldn't be much greater than for regular Sociables.
Except for those damned arrays. Maintaining a private copy that's reasonably optimal to access - and eventually reconcile -, without sucking down big chunks of memory, while coexisting with arbitrary unshift(), shift(), splice(), push(), and pop(), can induce a brainfever. Suffice to say POD needs a "flashing skull-and-crossbones" directive I can use when discussing the dangers of iterating over large arrays inside a transaction.
I still haven't figured out what *I* would ever use STM for in day-to-day Perl programming (I'm partial to the shared-nothing/Actor type model that apartment threading approximates), but I've some notions about adapting the storage mechanism to IPC shared memory, DSM, or memcached that might eventually justify this exersize.
If nothing else, it should shut up that nagging little voice...
