Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

renodino (6856)

  (email not shown publicly)

Perl Contrarian & SQL fanboy.

Here's my CPAN goods. []

Journal of renodino (6856)

Saturday March 31, 2007
09:50 PM

Thread::Sociable: STM beckons

[ #32863 ]
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...

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.