Messages in this thread |  | | From | "J. Dow" <> | Subject | Re: thread rant | Date | Fri, 1 Sep 2000 23:29:48 -0700 |
| |
(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/
|  |