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


in reply to Where is concurrency going? Is Perl going there?

Some PhDs (and me, too), think that threads are evil (pdf).

Favorite quote:

...non-trivial multi-threaded programs are incomprehensible to humans.

Replies are listed 'Best First'.
Re^2: Where is concurrency going? Is Perl going there?
by BrowserUk (Patriarch) on Jul 26, 2007 at 13:21 UTC
    Some PhDs (and me, too), think that threads are evil.

    PhDs don't like anything that they cannot put into nice theoretical boxes. The non-determanism of thread interactions (in fact, non-determanism in general), does not fit into any of their nice boxes--so it scares them.

    Newsflash. The world is non-determanistic(*). Get over it!

    ((*)And no, I do not want the theological debate :)

    Any non-self-contained program--ie. any program that uses data from outside of itself, via the keyboard or a file or a database--is non-determanistic. The world goes on. New, non-determanistic programs are written and used every day.

    The same goes for threads. The PhDs can run around like headless chicken writing all the theses they like about how threads can't work, aren't safe, cannot be proven, or ascribing them with metaphysical properties.

    The simple fact is that thousands of programmers are writing thousand of programs that use some flavour of threading every day. Half of the web is run, directed or controlled by threaded applications.

    The debate is not whether threads are useful, or will be used. It is simply about how they will be used. What abstractions will make their use more accessible. And, crucially in this forum, from what languages they will be used.

    ...non-trivial multi-threaded programs are incomprehensible to humans.

    Viewed as complete systems, most non-trivial programs are incomprehensible to humans. That's why we use abstrations.

    You know, for years the theoreticians went around claiming that the bumblebee couldn't possibly fly. And yet ...


    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.
      Well, I am not sure about theoreticians and their boxes, but I most certainly hate debugging threaded programs, be it C, C++, or anything else.

      To me, "thread" is spelled f-o-r-k. To each his own, I s'pose.

        If I have a problem that will benefit from concurrency, and doesn't need ongoing shared access to data, (and if I'm on a platform that has fork available), I'd probably use fork. Though, if no data sharing is required, then running independent subroutines in separate threads is just as easy to debug. Run each thread individually until it is (percieved) bug free and then start them all.

        But there are a whole class of problems that need ongoing access to shared data.

        Forked solutions to these problems mean serialising data and passing it (bidirectionally) through pipes or sockets, and that adds far more complexity and is even harder to debug than threads. Flattening and reconstituting compound data-structures is one problem. Coordinating bi-directional communications another. Synchronisation between processes is just as hard, and equally fraught with deadlocks and priority inversions as is synchronisation between threads.

        All the difficulties of concurrency exists regardless of the unit of concurrency (processes or threads) used. The only difference is that when using processes, communications is slower and adds complexity. The only way to handle bi-directional asynchronous communications without threads, is to use a select model state machine. State machines are far harder to program than the linear flows that can be used when you have threads.


        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.
Re^2: Where is concurrency going? Is Perl going there?
by erroneousBollock (Curate) on Jul 26, 2007 at 02:08 UTC
    I think what BrowserUK said is that (at least on hardware of the forseeable future) all methods of concurrency (except cooperative events, eg: POE) are necessarily based on something like is or works like CPU threads.

    I would tend to agree that the "Threads/Processes and Locks" paradigm is a terrible high-level concurrency abstraction... much too easy to make mistakes, and it's hard to apply to the majority of algorithms and data-structures we're all familiar with.

    I'm interesting in how we might tackle some of the more (currently) esoteric concurrency abstractions in Perl.

    -David.