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    [from the cache]
©2003-2011 Jasper Spaans