So, my question is, what mechanism could be used to avoid that

This is quite possibly a non-helpful response, but I think that "blessing" the new SV into package NULL is one way of avoiding the issue.
This effectively means that when the SV goes out of scope, it gets garbage-collected, but the object it points to survives (because DESTROY wasn't called). Therefore, any other SV's that point to the same object are still valid.
This also effectively means that the programmer has to take charge of determining if/when these objects are DESTROY()ed - or run the risk of memory leaks.

For some reason that I've never understood, I provided in Math::MPFR the capability of creating such unblessed objects and it does seem to me to provide a way of avoiding the problem. With an object blessed into package Math::MPFR:

use warnings;
use strict;
use threads;
use Math::MPFR qw(:mpfr);

my ($x, $inex) = Rmpfr_init_set_d(11.625, MPFR_RNDN);

my $thr1 = threads->create(
             sub {
                 print Rmpfr_get_d($x, MPFR_RNDN), "\n";
                 return 23;
                 } );       ## Line 12

my $res = $thr1->join();
print $res;

__END__

OUTPUTS:
11.625
Free to wrong pool 4ab7e0 not 49aee0 at threads.pl line 12.
[download]

With the unblessed object:

use warnings;
use strict;
use threads;
use Math::MPFR qw(:mpfr);

my ($x, $inex) = Rmpfr_init_set_d_nobless(11.625, MPFR_RNDN);

my $thr1 = threads->create(
             sub {
                 print Rmpfr_get_d($x, MPFR_RNDN), "\n";
                 return 23;
                 } );

my $res = $thr1->join();
Math::MPFR::DESTROY($x);
print $res;

__END__

OUTPUTS:
11.625
23
[download]

Maybe that's an overly simplistic and/or irrelevant demo. (My knowledge of threads is very week.)

Cheers,
Rob