Just to reinforce the point, could you give some general information of how much extra space is required to share a structure.
Eg. If a structure takes 10Kb as a non-shared entity, how much would it cost to share this with say 2 other threads (3 total)? Is it 30Kb, 40Kb, 50Kb extra?
Also, if you change a leaf (scalar) within that structure, how much slower is that than in a non-shared equivalent?
Finally, does the hit of updating the other copies of the modified value come
- all at once in the context of the thread that makes the modification?
- Or incrementally as the other sharing threads get a timeslice?
- Or does the sharing thread have to defer until each of the other threads get a timeslice in order to update their copies?
If the latter is the case, does the time the modifying thread waits for the others threads to update depend on the vagaries of the scheduler calling those threads (in competition with all other threads in the system), before the modifying thread can continue and unlock the modified scalar?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Very roughly speaking, a shared variable is implemented internally using a form of tieing. Each thread has its own copy of the tied variable, and the real value is stored in a separate area of shared memory. When you read a variable, the tied code gets called (XS rather than perl code), which locks the real shared value, then copies its value into the thread's private address space. Similary a write to a shared variable involves copying the private value into the shared variable.
So in a worst-case scenario:
my $s : shared = 'a' x 10_000;
for (1..100) {
async { my $l = length $s; sleep }
}
would consume about 1Mb, with each thread having a cached copy of the string at the point it was accessed.
Nested structures are more complicated than that, but roughly speaking the worst-case isn't as bad as the scalar case above.
Dave. | [reply]
[d/l] |
Nonetheless, a built-in facility or function to ease the process for the disciplined programmer would've been a nice touch. The contortions that we are forced to resort to in its absence betray an obvious deficit in the pragma's original vision. I can't agree that things that "encourage bad habits" are necessarily bad. Let's face it: Perl itself encourages bad habits -- as does any tool with similar power. It's up to the user to wield that power responsibly. | [reply] |