http://www.perlmonks.org?node_id=1094204


in reply to The problem with "The Problem with Threads"

Thanks for writing your thoughts about threads. I use threads, and I like them a bit more than most of the other ways to introduce parallelism and concurrency. I only have one quibble with your points:

The "heaviness" of P5 threading is a misnomer. The threads aren't heavy; the implementation of shared memory is heavy. And that could easily be fixed.

As the current implementation of threads tries to simulate parallelism within one interpreter, "fixing" that is not easy as long as you want the promise of implicitly shared things (like the namespace and tied variables most importantly) to remain there. If you move to a less implicit model of sharing, like your usual approach using a queue, and also remove the promise of changes being visible to every thread, or convert it to a threat/warning that changes become visible everywhere, without protection, then I can concur that threads could become less heavy. But as they are now, they are heavy and making the Perl environment look to several threads as if they were the only thread currently running makes them remain heavy.

Replies are listed 'Best First'.
Re^2: The problem with "The Problem with Threads"
by BrowserUk (Patriarch) on Jul 20, 2014 at 06:28 UTC
    As the current implementation of threads tries to simulate parallelism within one interpreter,

    After 24 hrs of thinking about that statement, I cannot make it gel with my knowledge that each thread starts a new interpreter.

    Given it is you, I assume I'm just misunderstanding your drift?


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    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.

      No, it was me who is simply wrong. Actually testing reveals that each thread really has its own namespace, like you say. So I'm less sure of where the actual problem or overhead lies with sharing data across threads, at least where the namespace is involved.