Imagine, if you will, that a “shared” object comes from an entirely different storage-pool. Both the object, and anything which that object refers-to, must be from that pool. If you want to attach a non-shared object, you must do so by making a clone of that object that is built out of memory taken from the shared pool. (So it is the clone, not the original non-shared object, that is ultimately attached.)

Shared objects can be, and of course must be, “locked” to avoid contention between the threads, and when you do this, the outermost object must be the thing that you lock and unlock. (In this case, that would be $self.)

threads::shared (and its brethren) conveniently provide a counting semaphore semantics, giving each lock an atomic counter such that the lock is not considered to have been “released” until the count has become zero. To make it less likely that you would accidentally hose-it-up ... :-D ... they don't provide a direct unlock capability, relegating all of that to the destructor. Their implementation of bless() is also fundamental, but demands crystal-clear understanding of how and why it works.

Remember always that these locks are advisory in nature. This is why you must always have an agreed-upon protocol of exactly what you intend to lock, and in what order. The “outermost object” protocol is consistently good, because many memory-manipulations take place behind the scenes when you are dealing with related-things that something “refers to.” Reliability, in these cases, generally trumps any un-proved notions of efficiency.