in reply to using parallel processing to concatenate a string, where order of concatenation doesn't matter

You're misunderstanding what Parallel::ForkManager does, I'm afraid. (As long as it actually does use fork, which seems likely from the name).

When fork() (the underlying system call) is called, the process is split into 2 identical copies, and the fork call returns in each copy, indicating by its return value which copy is which. (That's a simplified view, but it'll do for now)

So your concatentate_parallel function is effectively adding a letter to $content in each subprocess, but that doesn't affect the parent process (your main application) where $content remains unchanged.

You can find a lot of good info online about how fork works, what the variants are, what gets copied for subprocesses and what doesn't. It's a good thing to understand.

By the way, if you'd been using threads instead, you'd have been on the right path. Threads are simultaneous paths of execution in the _same_ process, so different threads could modify $content. But without using synchronization mechanisms, you're right, the letters would arrive in a jumbled, unpredictable order.

Good luck!


Mike
  • Comment on Re: using Paralell::ForkManager to concatenate a string, where order of concatenation doesn't matter

Replies are listed 'Best First'.
Re^2: using Paralell::ForkManager to concatenate a string, where order of concatenation doesn't matter
by tphyahoo (Vicar) on Oct 18, 2006 at 11:17 UTC
    Thanks, you are surely right (see my update).

    So ok, how do I do this with threads in the cleanest possible way?

    Basically what I am after is a way to transform the serial code into the parallel code with a minimum amount of fuss, and a minimum amount of typing. And be reasonably certain that it will work.

      If you are on UNIX, take a look at shmread and the associated links in perlfunc.