Re^2: passing hashes between threads

If a copy was not made, by the time the reader got a hold of (what?: a reference to) the hash, the feeder will have already overwritten it with the next record. Or worse, partially overwritten it.

I understand that. But if I do something like:

sub WorkerThread {
    while ( $element = $wq->dequeue ) {
        $hashref = DoWork($element);
        $qq->enqueue( $hashref );
    }
}
sub DoWork{
    my %hash
    .....
    return \%hash;
}
[download]

Why is the my %hash not doing the trick. It should be new hash-reference every time DoWork() is called. Do I miss something?

Comment on Re^2: passing hashes between threads Download Code

Replies are listed 'Best First'.
Re^3: passing hashes between threads by BrowserUk (Patriarch) on Sep 18, 2011 at 12:52 UTC
Okay. I'll put it another way. That is the way iThreads, explicitly-shared-only data model works. In order that the programmer needn't be concerned with locking, variables declared in one thread cannot be seen, or passed directly to, other threads in the process. When you give a reference to a non-shared variable to Thread::Queue (or any other mechanism that will convey unshared data between threads), it has to make a copy of the unshared data into the shared data-space. And when you read a reference out of a queue and and dereference it into a non-shared variable in the other thread, the copy process --- this time from the shared data-space to the thread-local data-space -- has to happen again. The way to avoid the copying, is to declare the data you wish to share in the shared space up front. You can then access it from any thread without copying it. Though you then have to concern yourself with locking. 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^3: passing hashes between threads
by BrowserUk (Patriarch) on Sep 18, 2011 at 12:52 UTC

Okay. I'll put it another way. That is the way iThreads, explicitly-shared-only data model works.

In order that the programmer needn't be concerned with locking, variables declared in one thread cannot be seen, or passed directly to, other threads in the process. When you give a reference to a non-shared variable to Thread::Queue (or any other mechanism that will convey unshared data between threads), it has to make a copy of the unshared data into the shared data-space.

And when you read a reference out of a queue and and dereference it into a non-shared variable in the other thread, the copy process --- this time from the shared data-space to the thread-local data-space -- has to happen again.

The way to avoid the copying, is to declare the data you wish to share in the shared space up front. You can then access it from any thread without copying it. Though you then have to concern yourself with locking.

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]