Re^6: ithreads, locks, shared data: is that OK?

Thanks Choroba for your time. I am bit apprehensive to start a thread to act as a data-query server. What about the communication overhead? Bottlenecks?

*Or* does a Thread::Queue or a threads::shared hash imply the exact same overheads and bottlenecks because of Perl's ithreads implementation?

summary: what you propose and my workflow:

Your suggestion: start a thread to handle enquiries about data (remember i need to do 2 checks, 1 if word is currently being processed and 2 if word has already been processed) and maybe also put the dictionary in there. So that eliminates all shared data and insane duplication of a readonly dictionary over all threads.

my workflow: I am keeping track of first 2 cases above using a queue which I basically (mis-)treat as a hash. I loop over its elements and peak() trying to find my word. Or I loop and peak() and if found, I dequeue() it. Ideally I should have used a shared hash for each of the two words. And a shared dictionary.

Comment on Re^6: ithreads, locks, shared data: is that OK? Download Code

Replies are listed 'Best First'.
Re^7: ithreads, locks, shared data: is that OK? by choroba (Cardinal) on Sep 20, 2018 at 16:06 UTC
It was just an idea. If you have enough time, try all the solutions, benchmark, compare readability. Using shared variables means you need locking, which is complex and can go wrong. Peaking means you need to lock the queries, which slows down the work and introduces locking, which is complex and can go wrong :-) ($q=q:Sq=~/;[c](.)(.)/;chr(-\|\|-\|5+lengthSq)`"S\|oS2"`map{chr \|+ord }map{substrSq`S_+\|`\|}3E\|-\|`7**2-3:)=~y+S\|`+$1,++print+eval$q,q,a, [download]	[reply] [d/l]
Re^8: ithreads, locks, shared data: is that OK? by bliako (Abbot) on Sep 20, 2018 at 16:52 UTC
OK. This is what I wanted to confirm. I think I am on the right track in the sense I am not doing things upside-down, I will experiment with the options. thanks for the advice. bw bliako	[reply]