develooper Front page | perl.perl5.porters | Postings from August 2001

pp_lock, lock, scoped locking and so on

Thread Next
Arthur Bergman
August 10, 2001 08:27
pp_lock, lock, scoped locking and so on
Message ID:

I have been looking on how to implment scoped locking and the only way to do
it is inside pp_lock, this means moving threads::shared lock code into the

Right now a shared sv is a struct containing

owner (of lock)

Then the sv representing this keeps it in a magic field and works as a proxy
to the shared_sv->sv, this is all defined in shared.xs now.

The following functions today are generic and not implmenting the proxy

init_shared_sv() /* inits the structures but does not creat the SV inside,
returns a SVIV which is a pointer to the struct
shared_lock() /* does recursive locking
shared_unlock() /* unlocks, but this is going away since we are going to
dynamicly scope them
shared_thrcnt_inc() /* safely increments the thrcnt_inc
shared_thrcnt_dec() /* decrements the thrcnt and frees whatever is needed to

They should probably be moved in perl space somewhere. Somewhat akin to
xsutils.c and change the names.

I suggest svshared.c and svshared.h with the following functions


Right now I use SVIVs as pointers in the internals (an shared arrays entry
is a sviv to a shared_sv struct), is the interface ok or should we only
interact with struct pointers?

Possibly a 
Perl_get_shared_sv(SV* frontend sv)
Perl_set_shared_sv(SV* frontend sv, shared_sv_struct *);

SV*  Perl_checkout_shared_sv(SV* frontend sv);
#do work on the backend sv here
Perl_commit_shared_sv(SV* frontend sv);

The checkout and commit will lock and set the perl context for working with
the SV* and then unlock and move the context back. Owner is used to keep the
context inbetween.

Comments, no comments will result in a svshared.c and svshared.h look like
this :).


Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About