Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re^6: shared scalar freed early (block)

by chris212 (Scribe)
on Feb 24, 2017 at 15:40 UTC ( #1182740=note: print w/replies, xml ) Need Help??

in reply to Re^5: shared scalar freed early (block)
in thread shared scalar freed early

It will only block between threads with testa (my approach) if the next thread to output is not the first one finished. As soon as the next thread to output is finished, a thread is created for the next chunk to be processed. This can probably even be improved if I up the semaphore at the end of the worker thread instead of after the next one to output is joined.

With testb (your approach), the semaphore is up'ed as soon as any chunk of data finishes processing allowing another chunk to be queued and processed. That should theoretically be more efficient, but it isn't. It is 5x slower. Even with ikegami's clean and elegant solutions using your approach, it is till 5x slower. I suspect it has to do with how memory is managed passing data structures to threads as opposed to making it shared in a queue.

  • Comment on Re^6: shared scalar freed early (block)

Replies are listed 'Best First'.
Re^7: shared scalar freed early (just queues)
by tye (Sage) on Feb 24, 2017 at 19:10 UTC
    With testb (your approach), the semaphore is up'ed

    No, with my approach, there is no semaphore.

    Create N threads. Have them read work items from an input queue. Create an output thread that reads items from an output queue. Now feed input to the input queue. Create a work item by sharing a new HASH or ARRAY ref. Store a sequence number into the work item. Store what the worker needs to know into the work item. Add the work item to the input queue. When a worker thread pulls a work item, it replaces what only it needs to know with what it computes and then puts the result (still containing a sequence number) into the output queue.

    The output thread just pulls stuff out of the output queue. It starts off knowing nothing other than the first sequence number. When it pulls a work item, if that work item's sequence number matches the next sequence number, then it can output it immediately. If not, it stores it into a not-shared hash with the sequence number as the key. Every time it outputs something it also increments the sequence number and looks the result up in its local hash. If that finds a match, then it deletes it from the hash and outputs it (which triggers a repeat of this process).

    If I were writing it, I'd probably at least look at having the main thread handle both input and output. Then it could track (with a simple non-shared counter) how many work items are potentially in the combined queues and avoid letting that build up too high so that the sources of inputs can notice that intake is falling behind instead of just having RAM usage grow unbounded with no other signs of problems.

    - tye        

      How is that different from ikegami's code which uses an input queue and an output queue with a sequence number? That is still 5x slower.

        Probably because of how inefficient threads::shared is at copying a lot of separate items between threads. When your threads do almost no work and you pass a lot of data, your threads are making things slower rather than faster. One uses threads because one has significant work to do (and not much data to move around -- unless you can use shared memory structures, which aren't easy to do in Perl). You'd probably get a big speed boost in this case if you used forks (but that won't run on Windows). But it will probably still be slower than if you just added no concurrency for this (unrealistic, I presume) work load.

        - tye        

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1182740]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (2)
As of 2022-07-06 19:47 GMT
Find Nodes?
    Voting Booth?

    No recent polls found