Re^3: threads::shared - when to lock a hash ?

Perl internally locks the variable before reading from or writing to it

Thanks, I should have thought that perl somehow protects its internal state. I couldn't find anything in threads::shared manual, so I looked into source and what I understand is that perl locks not just variable but the whole shared space, is it correct?

Comment on Re^3: threads::shared - when to lock a hash ?

Replies are listed 'Best First'.
Re^4: threads::shared - when to lock a hash ? by dave_the_m (Monsignor) on Oct 17, 2011 at 06:53 UTC
perl locks not just variable but the whole shared space, is it correct? Yes. All shared variables are kept in a separate interpreter, with stub copies of the variable in each thread, and a tieing mechanism used to access the vars. So when you do something like $shared_var = 1, your thread notes that $shared_var is tied, an calls the STORE method (which happens to be implemented in XS for efficiency). This method sets a global lock and copies the new value to the 'real' variable. Dave.	[reply]

Replies are listed 'Best First'.

Re^4: threads::shared - when to lock a hash ?
by dave_the_m (Monsignor) on Oct 17, 2011 at 06:53 UTC

perl locks not just variable but the whole shared space, is it correct?

All shared variables are kept in a separate interpreter, with stub copies of the variable in each thread, and a tieing mechanism used to access the vars. So when you do something like $shared_var = 1, your thread notes that $shared_var is tied, an calls the STORE method (which happens to be implemented in XS for efficiency). This method sets a global lock and copies the new value to the 'real' variable.

Dave.

[reply]