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

I tend to believe dave_the_m because I'ver never used locking in any of my threaded scripts, and as of yet, never seen a problem. dave_the_m even commented on some old script of mine, without locking used, and mused hmmmm,.. some sort of low-level atomic locking seems to be occurring automatically

Just like a Prime Directive :-)

But I will quote his fine print:

Of course in all the above, "safe" means "not corrupting perl's internal state"; perl's internal locking causes all the reads and writes to be serialised. You may of course still need to do locking at a higher level to ensure the safety of your own code's logic

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh

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 BrowserUk (Patriarch) on Oct 16, 2011 at 20:50 UTC
I'ver never used locking in any of my threaded scripts, But, if I recall correctly, you do not use a multi-core processor. Running threads on a single-core processor -- where only one thread will ever actually be running at any given moment in time -- means that you can get away with a great many dubious practices that will come back to bite you in the ass when you move the code to a multi-score processor -- where 2 or more threads may be running concurrently on different cores. Also, you have almost certainly used elective locking without being aware of it. Thread::Queue uses locking to ensure safety. Indeed, often the simplest way to get a threaded application running is to use that module to start, and then revert to using a shared array (which is all a Queue is underneath) and perform selective locking to improve performance. But I will quote his fine print: Indeed. As he pointed out. If you are inserting and deleting elements from a hash or array in one thread, and iterating it in another, the iterating (reading) thread needs to lock the hash otherwise it will get inconsistent results. Ie. the reader may iterate over elements that are subsequently removed (by another thread) before the iteration has completed, or it may miss newly inserted elements. If instantaneous consistency is important to the algorithm -- which is actually far rarer than you might think -- then the reader must lock the hash while the iteration is in progress. But the need for locking is certainly not "`anytime'"; nor "dictated"; nor "comprehensive". Prosaically, safe practice is to lock everything, everytime. But the downside is a substantial hit on performance. In almost all cases it is not just possible, but advisable to relax locking where it can be reasoned (or demonstrated) to be unnecessary. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]

Replies are listed 'Best First'.

Re^4: threads::shared - when to lock a hash ?
by BrowserUk (Patriarch) on Oct 16, 2011 at 20:50 UTC

I'ver never used locking in any of my threaded scripts,

But, if I recall correctly, you do not use a multi-core processor. Running threads on a single-core processor -- where only one thread will ever actually be running at any given moment in time -- means that you can get away with a great many dubious practices that will come back to bite you in the ass when you move the code to a multi-score processor -- where 2 or more threads may be running concurrently on different cores.

Also, you have almost certainly used elective locking without being aware of it. Thread::Queue uses locking to ensure safety. Indeed, often the simplest way to get a threaded application running is to use that module to start, and then revert to using a shared array (which is all a Queue is underneath) and perform selective locking to improve performance.

But I will quote his fine print:

Indeed. As he pointed out. If you are inserting and deleting elements from a hash or array in one thread, and iterating it in another, the iterating (reading) thread needs to lock the hash otherwise it will get inconsistent results. Ie. the reader may iterate over elements that are subsequently removed (by another thread) before the iteration has completed, or it may miss newly inserted elements. If instantaneous consistency is important to the algorithm -- which is actually far rarer than you might think -- then the reader must lock the hash while the iteration is in progress.

But the need for locking is certainly not "`anytime'"; nor "dictated"; nor "comprehensive".

Prosaically, safe practice is to lock everything, everytime. But the downside is a substantial hit on performance. In almost all cases it is not just possible, but advisable to relax locking where it can be reasoned (or demonstrated) to be unnecessary.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

[reply]