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

[BrowserUk]

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.