On Thu, May 09, 2002 at 02:16:05PM +0100, Nick Ing-Simmons wrote: > Tim Bunce <[EMAIL PROTECTED]> writes: > > > >Since many extensions to non-threadsafe libraries probably need simple > >mutex protection, perhaps that could be bundled up into a single > >macro (and added to ppport.h as well). Then extension authors can > >be told to "just add this macro" where needed (possibly every entry > >point). > > sv.h has : > > =for apidoc Am|void|SvLOCK|SV* sv > Arranges for a mutual exclusion lock to be obtained on sv if a suitable module > has been loaded. > > This acquires a lock based on an SV (see threads/shared.xs for the current > implementation). > > It is modeled after Malcolm's lock operator in that it is recursive > and scoped. It is necessarily more expensive than the MUTEXT_XXXX > stuff. I opted for that scheme as with ithreads we only "share" SVs > so a shared SV was the obvious thing to use - and given the overhead > of "magic" and context swapping to get at the shared SV the extra couple > of hoops for recursive and scope seemed like value-for-time. > (Having driven all the way to the Supermarket and parked, we may as > well buy a proper meal, rather than just a snack.) > > XS Usage would be > > As part of setup > SvSHARE(tokensv); > > ... > ENTER; > SvLOCK(tokensv); > do stuff > LEAVE; > > SvLOCK() and SvSHARE() are safe to call even in non-threads as they stubs > until (say) threads::shared::bootstrap() populates the function pointers.
I see threads.pm says: : It is also important to note that you preferably enable threads by : doing C<use threads> as early as possible and that it is not possible : to enable threading inside an eval ""; In particular, if you are : intending to share variables with threads::shared, you must : C<use threads> before you C<use threads::shared> and threads will emit : a warning if you do it the other way around. but "preferably" seems way too weak. You *must* use threads and threads::shared if required *before* loading any extensions (or any module that might load extensions). I think it would be good if the stub hooks for SvSHARE and SvLOCK incremented a counter. Then if threads.xs is loaded and the counter is non-zero a warning can be given. > If you want same kind of abstraction for lighter-weight non-recursive > MUTEX stuff now would be a good time to make the case. SvLOCK doesn't look too expensive. And it's basically doing just what the DBI already does (looping on a COND_WAIT). So I'm happy to dump my code and use yours :) Thanks. There ought to be some pointers to this stuff in perlguts and perlxs. Currently only perlapi.pod mentions SvSHARE and SvLOCK (and you have to know what you're looking for before you read perlapi.pod :) Both should refer to each other and mention the interaction with the threads module. Thanks for the pointers Nick. Tim.
