threading bug with lvalue subs

Consider this:

    BEGIN {  
        my $Datum = "Start Value";
        sub A_Class_Method ($;$) : lvalue : method {
            my $class_or_obj = shift;  # we care not the invoker's nature
            croak "expected only one arg, not @_\n" if @_ > 1;
            lock $Datum;
            $Datum = shift if @_;
            return $Datum;
        } 
    } 

I've got a bad feeling about this.  If you call that method:

    The_Class->A_Class_Method = "uno solo";

Notice when the lock is gained and when it is freed.  It's a lexical
lock, os it's dropped as the block scope exits.  But I bet that's
too late, isn't it?  Where logically does the assignment occur?
Inside or outside the protective scope?  Outside, right?

Now, how does this play with 5.6 threads vs 5.005 threads?  Does it play 
at all?  I bet that I'll have to write:

    my $Datum : shared = "Start Value";

Since otherwise I don't see how the the separate interpreters will
even see that value.  And if they do, then I'm concerned about the
locking on lvalue subs.

Please advise.

Thank you.

-tom

• threading bug with lvalue subs by Tom Christiansen