Front page | perl.perl5.porters |
Postings from February 2012
Aaron Crane wrote: >Do we support any platforms where an access to a Perl_check_t might >not be atomic? ... >If so, I think the OP_REFCNT_LOCK needs to precede the initial >test/return, to avoid this race: If so, then we'd need a mutex around all reads of PL_check entries during op checking. Currently they're unlocked. I think for pointer reading to be non-atomic is rather unlikely, and would cause a great many problems of this nature all over the code. Not worth worrying about. (Btw, if pointers cannot be read atomically then you don't move the lock operation there, you remove the inital check entirely. It's redundant with the check that occurs in the locked section: it exists only as an optimisation, to avoid the expense of acquiring the lock in a common case.) -zeframThread Previous