(Hm, I meant for a copy of this to go to the list, too. So here it is.)
Mike Harris comments:
> > I've heard comments from Alan, and others in the past bashing
> > threads, and I can understand the "threads are for people who
> > can't write state machines" comments I've heard, but what other
> > ways are there of accomplishing the goals that threads solve in
> > an acceptable manner that gives good performance without coding
> > complexity?
>
> Threads are a handy way to allow a prioritized state machine
> operations. State machines are nice and I use them and have
> used them to good effect. (The MX3000 SatCom modem data
> mode and fax mode are both state machines - as far as the
> Inmarsat spec vs the Facsimile spec allowed.) I also use
> multithreaded code. I use it when I want to switch from thread
> to thread based on input events and priority. I don't want to
> continue to run through a low priority "state" before I can service
> a high priority "state". Threads are the mechanism. People who
> make declarations such as you cite remind me of people who
> yank the gas pliers out of their back pockets to pound in 10
> penny nails. If you need a hammer and do not have one then
> any tool begins to look like a hammer.
>
> > This is all just curiosity. I've considered trying some thread
> > programming, but if it is as stupid as it sounds, I'd rather
> > learn the "right" way of writing code that would ordinarily be
> > done with threads, etc.. Right now, I'm using fork() all over
> > the place and don't much care how much waste it is... I'd like
> > to though.
>
> Think on what it is you want to do. State machines are REAL
> good when every state should run to completion before you
> run the next state. State machines are not good when your
> program has functions that must be run at a higher priority
> than the other's while the others must not block when the
> higher priority thread blocks. Use the two tools with some
> discrimination and you can get wonderful results.
>
> > >The fact that the system implements threads speaks enough about
> > >it's capabilities. ie, it's trying hard to suck less. So, from my POV,
> > >we're looking to make Linux suck more by effectively emulating systems
> > >that are trying to suck less.
> >
> > Makes sense... if you understand the details of why threads
> > suck. I understand there are some cache coherency issues, and
> > I've heard of other things as well, but is there an FAQ out there
> > saying "Why to not use threads?" that goes into good detail and
> > provides alternatives?
>
> Doesn't make sense to me, Mike. But then I use threads where
> threads are appropriate and state machines where state machines
> are appropriate and linear code where linear code is appropriate.
> Consider threads a tool. Learn how the tool works. Then select it
> and use it when the situation warrants it.
>
> > >But, I've never done anything worthwhile for Linux, so take this for
what
> > >it's worth, from an asshole.
> >
> > Works for me. ;o)
>
> Sometimes I remember I am a lady and that ladies don't reply to that
> level of comment. 'Sides, if I did reply it'd not be by fainting. He might
> discover a new apperature somewhere on his body that resembles
> the orifice referenced that he didn't plan on or have OEM.
>
> {^_-}
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 02 2000 - 02:31:59 EDT