lkml.org 
[lkml]   [2001]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Alan Cox quote? (was: Re: accounting for threads)
    Date
    On Wednesday 20 June 2001 11:33, Alexander Viro wrote:
    > On 20 Jun 2001, Jes Sorensen wrote:
    > > Not to mention how complex it is to get locking right in an efficient
    > > manner. Programming threads is not that much different from kernel SMP
    > > programming, except that in userland you get a core dump and retry, in
    > > the kernel you get an OOPS and an fsck and retry.
    >
    > Arrgh. As long as we have that "SMP makes locking harder" myth floating
    > around we _will_ get problems. Kernel UP programming is not different
    > from SMP one. It is multithreaded. And amount of genuine SMP bugs is
    > very small compared to ones that had been there on UP since way back.
    > And yes, programming threads is the same thing. No arguments here.

    Hopefully in 2.5 we'll get the pre-emptive UP patch in that enables the SMP
    locks on UP and finally clean it all out by exposing the bugs to the main
    user base.

    As for multi-threaded programming being hard, people are unfamiliar with it.
    Any programming is hard the first time. And almost anybody's first attempt
    at it is going to suck. (Dig out the linux kernel 0.02 sources sometime and
    compare them with what we have today.)

    The more experience you get with it, the better you are. Encouraging people
    to stay away from it rather than learn to do it RIGHT is the wrong attitude.
    People will figure out that using 1000 threads when you need 3 isn't the best
    way to go, that locking is an expense but failing to lock is worse, how to
    spot race conditions (the same old "security" mindset except you don't need a
    malicious third party to get bitten by it.)

    And they'll learn it the way I did, and the way everybody does. Do it wrong
    repeatedly. Make every mistake there is, hard. Get burned, rewrite it from
    scratch four times until you figure out how to design it right, spend long
    weekends looking for subtle little EVIL bugs you can't reproduce but which
    bite you the instant you stop looking for them, learn to play "hot potato"
    with volatile data you have to manipulate atomically...

    Everybody starts as a bad programmer. Some of us get it out of our systems
    when we're 12. Others decide programming is lucrative when they're 35 and
    inflict their "hello world" opus upon their coworkers. Me, I wrote a disk
    editor and a bunch of bbses in 5th and 6th grade back on the C64 that will
    never see the light of day. And yes they sucked. But I'm still proud of
    them. And I wrote awful multithreaded code back on OS/2, and can now write
    decent threading code because I've learned a large number of things to avoid
    doing. And I take proper care because I know how hard it is to FIND one of
    these if you do wind up doing it. I've done it. Once for two consecutive
    weeks on the same #%*(&#%& bug. There's no WAY somebody's going to pick that
    sort of thing up in a programming course, or from "advice" from experienced
    people. We never listen to advice from experienced programmers. If we did
    we'd still be using Fortran for everything...

    Rob
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:55    [W:0.046 / U:0.952 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site