|Do you know where your variables are?|
Re^2: what the history behind perl not having "real" threadsby perl-diddler (Hermit)
|on Feb 26, 2013 at 06:59 UTC||Need Help??|
dave the m wrote:
5.0005 threads (introduced with perl 5.005) by default shared all data and data structures. This turned out to be almost impossible to make thread-safe, since almost any perl-level "read" operation can actually end up modifying an SV (scalar value).Is this required by the language, or, evolving from your examples:
I wouldn't see a simple 'my' var as needing sharing, unless you take a reference to it..., package vars might be ideal for something like a Fortran COMMON section, if I remember what I'm talking about... i.e. GLOBAL vars/package (that would be shared).
But if I print $x, does it have to modify "$x", or -- rather why not leave it alone and have print modify a copy -- it's not like it is being stored somewhere that a shared implementation might expect to be able to access it's 'mutated form' ;-).
As for your 3rd line, referring to the ref count, that's definitely something the interpreter would need to track, but wouldn't be hard to implement on the x86 as, as long as the counter is arch-word (32/64bit) aligned, an inc/dec operation is atomic.
The thing that is annoying about the current model is, from my understanding, the limitation on having to pre-declare something as shared or not -- which would, it seems, preclude using it with object oriented programming where specific objects could have global state (and need locking in the presence of multiple writers) -- but not multiple readers.
But the good news, as I understand you saying, is that the current code uses native OS threads -- it's just that they don't share much [if any] data...that's slightly better than I thought it might be given that under linux today, a fork-exec you can choose multiple levels of sharing and code segments of compiled programs can automatically share the same code memory (presuming they weren't built statically).
Thanks for the info....