Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re^5: Parrot, threads & fears for the future.

by tirwhan (Abbot)
on Oct 24, 2006 at 10:16 UTC ( #580230=note: print w/replies, xml ) Need Help??

in reply to Re^4: Parrot, threads & fears for the future.
in thread Parrot, threads & fears for the future.

<shrug> to be honest, I have no real desire to debate the pros-and-cons of threads with you, because I have in the past tried (and failed) to understand what kind of mindset is required to simultaneously consider programming state machines difficult and thread-induced problems manageable. Personally, I'd amend renodino's amendment to:

Threads are for people who can't have better things to do than program state machines but instead prefer to waste time debugging concurrency and verification issues

but that's just me. I suspect it's a kind of vim vs. emacs and Linux vs. Windows debate, so best left alone.

But your post does indicate to me that you probably still don't know who Alan Cox is and haven't looked into the history and discussion surrounding that quote. You may want to consider doing that (and here's a quick pointer at one such discussion), you might learn something and become a bit more cautious with the word "elitist". Just a thought.

All dogma is stupid.

Replies are listed 'Best First'.
Re^6: Parrot, threads & fears for the future.
by BrowserUk (Pope) on Oct 24, 2006 at 10:42 UTC

    I'd love to learn the context behind the quote, but your link leads me to a usenet post that add's this

    Actually he left out the apostrophe and didn't capitalize `computer'. See, e.g., +mail-archive/linux-kernel/2000-January/3533.html

    Which unless I'm being terribly obtuse tells me nothing at all?

    And if you follow the link in that, leads to 3 identical copies of the same post on different servers. Which doesn't help either. So I am still without the context from which the quote was drawn, and frankly cannot image any context in which it could be seen as anything other than elitist?

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Right, sorry I guess I was a bit brief, the post I linked to spawned a thread (hoho) of discussion which contains interesting background and several pertinent posts such as this, this and this (that last one is also a good example of what I meant about the "religiousness" of the thread-debate). That's not where the quote came from, that's here, which is a different (albeit also interesting in this context) discussion.

      ...and frankly cannot image any context in which it could be seen as anything other than elitist?

      Here's a hint: it says something very different from what you think it says :-)

      All dogma is stupid.

        I agree that there are very few situations in which more than a handful of kernel threads is needed. In almost every case, a 1000 kernel-threaded process is bad programming. But even in context, it still reads as elitist to me?

        > the IBM paper), that if your application depends on huge numbers of > threads, you're always going to keep bumping up against the schedule +r? > a lot of people throw lots of threads at a problem and it can really + > be bad design. That is the least of your worry. 1000 threads is 8Mb of kernel stacks, + and enough switching of tasks to be sure you might as well turn most of yo +ur cache off. A computer is a state machine. Threads are for people who c +ant program state machines.

        Unfortunately the link to the IBM paper referred to above is a dead end*. That sounds interesting and may have cast a different light on things?

        *IBM have been shuffling their links again. Why do corporations do that I wonder? MS are always doing the same damn stupid trick.

        Then again, when I worked at IBM, I remember going through 4 offices moves and three department name changes in 10 months. Two of them (offices and dept. names) in a 1 month period! The really stupid part about it is that each time I moved to a different (identical or mirror image) office within the same corridor!.

        Too many people with not enough to do, so they "shuffle resources" as a make-work exercise. People, offices, web pages, they're all the same thing--just resources.

        With respect to the difficulty of threads versus the difficulty of state machines. In the type of programming that Mr.Cox does, state machines work. Ie. In those scenarios where events arrive every few milliseconds and the actions required take (less) milliseconds, its a natural fit. (Still hard, but natural.)

        In application programs where some events require 1/10th seconds response times, and others take 10 of seconds, or minutes, or hours, breaking the long bits up into 1/10th second lumps so you can service the fast bits in a timely manner is a nightmare.

        Conversely, the typical application scenario for threading; one thread runs a state machine to service a GUI; whilst another thread issues DB queries, waits for the response and then supplies the retrieved data to the gui in nice small chunks via it's event queue; whilst another thread monitors a directory for the arrival of a file and informs the GUI it's there; and another is started to read that file into memory and feed into a display buffer or edit widget for the user to mess with. Threads are a natural fit for this. No where in that scenario is there any need for locking. No opportunities for deadlocks.

        Even proving correctness is simple. Each threads code is a simple loop, blocking at the top waiting for it's start event and running linearly through it, processing, before looping back to the top. Each threads code can be tested in isolation of the others. The only thing open to timing errors is the initiation event--and that's controlled by the user, via the state machine running in the GUI thread.

        Try writing that scenario as single threaded state machine and getting it to run efficiently on a range of different spec'd processors. Having tried, I know it's a nightmare.

        Threading does not have to be hard. Avoiding deadlocks is easy:

        ... { lock $variable; $x = something } ...

        Those curlies delimit the life of the lock. If you never try to acquire two locks concurrently, you can never deadlock.

        Now, if every time you want to access shared state, you are going to lock it, do your stuff and then unlock before doing anything else. Then the 'system' can do that for you. It knows which variables are shared, and it can bracket every access to those variables with the locking. Then the whole shared state problem goes away. You simply declare the data shared and the system (compiler, interpreter, whatever) always remembers to lock and unlock the variable each side of that access.

        No, this is not the fastest way to used shared state, but when the alternative is sending the shared values back and forth through sockets or other interprocess mechanism, it's still way faster. And simpler.

        The other main argument that is claimed to make threading hard is debugging. This is incorrect. The problem that makes debugging threads hard, is bad coding. If you try to write close coupled routines and run them across threads, you make a world of grief for yourself. So don't do that. Close coupled code is a no-no anywhere, threads exacerbates the problem for sure, but the problem has to exist in the first place.

        Debugging threaded code should be, and can be simple. Much simpler than state machines. The code in each thread should run perfectly happily as a standalone process with shared variables being no different to reading data from a db; or a file, or from a socket. For testing, substitute a tied var that randomly takes on values in the required range (and out of range forerror handling checks) each time you read it; and does nothing in particular ('cept maybe waits for a while) when you write to it. There is a complete method for testing all threaded application code.

        What about timing issues I hear someone ask. Simple, there are none. If there are, you are trying to synchronise threads and that's silly. So don't do that.

        Even this threaded MapReduce problem that floating around is trivial. It can be written in 20 lines of code using Perl and iThreads and existing, well known and tested modules.

        Things are more complicated in C. There, it is possible to scribble all over memory. That's bad enough and hard enough to track down in a single threaded program. It is a nightmare in a multi-threaded program. But Perl doesn't let you do that without really, really going out of your way to do so, or as a the result of a interpreter bug.

        Threading is perceived of as hard because whenever it comes up, all the "we don't need no stinkin' threads" crowd trot out the same tired old scenarios in which threads can cause deadlocks and corruption without ever mentioning that you only arrive at those situation if you do something stupid. And that just as with any other form of coding, if you don't do the stupid things, you don't get the problems.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (4)
As of 2021-06-17 07:50 GMT
Find Nodes?
    Voting Booth?
    What does the "s" stand for in "perls"? (Whence perls)

    Results (83 votes). Check out past polls.