Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re^7: shared scalar freed early (just queues)

by tye (Sage)
on Feb 24, 2017 at 19:10 UTC ( #1182748=note: print w/replies, xml ) Need Help??

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

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        

  • Comment on Re^7: shared scalar freed early (just queues)

Replies are listed 'Best First'.
Re^8: shared scalar freed early (just queues)
by chris212 (Scribe) on Feb 24, 2017 at 19:33 UTC
    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        

        FYI, the worker threads in my script do a lot of work, but they also require a lot of data. It most definitely is faster using concurrency. I'd rather have a dozen cores being utilized than one. I don't think forks wouldn't allow me to write output to the same file in sequence without some kind of IPC which would probably slow things down, and sorting afterward would take too long.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (6)
As of 2022-08-17 15:53 GMT
Find Nodes?
    Voting Booth?

    No recent polls found