Locking tends to equalize performance for a single shared/sociable operation inside the lock scope...but the perfomance delta rapidly improves with each additional operation inside the lock.
Once the embedded queueing implementation is complete, and Thread::Apartment is updated, apartment threaded method calls should be much snappier.
The addition of a tie-like capability (required to complete
will enable some intriguing applications: when thread A writes to a sociably tied
scalar, threads B, C, D, etc. can all fire their own STORE() methods.
What a multithreaded FETCH() means remains a bit of a puzzler
(some sort of sequencing interface is needed so thread A
can decide which of thread B, C, and D's FETCH() ultimately
Some additional observations:
Stack tuning solved part of the footprint issue. Thread::Sociable hopefully trims much of the fat from shared variables. Wish I had the lore to do iCOW...