Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!newsfeed.internetmci.com!news.kei.com!uhog.mit.edu!uw-beaver!nntp.cs.ubc.ca!cs.ubc.ca!gambier.ugrad.cs.ubc.ca!not-for-mail From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) Newsgroups: comp.unix.bsd.freebsd.misc,comp.unix.advocacy Subject: Re: Win32 CreateThread() vs Unix fork() Date: 12 Dec 1995 15:36:50 -0800 Organization: Computer Science, University of B.C., Vancouver, B.C., Canada Lines: 59 Message-ID: <4al3miINNmqt@gambier.ugrad.cs.ubc.ca> References: <4ab85f$idq@news.voicenet.com> <DJBt1u.GFD@tigger.jvnc.net> <4akmsb$qa3@shellx.best.com> NNTP-Posting-Host: gambier.ugrad.cs.ubc.ca Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:10357 comp.unix.advocacy:12143 In article <4akmsb$qa3@shellx.best.com>, David Paigen <paigen@shellx.best.com> wrote: >jlucas@uvi.edu (John Lucas) writes: > >>Threads are just another name for "lighweight process"; you often need >>"heavyweight processes" too. :-} > >LWP first came to the commercial unix world, AFAIK, via SunOS circa '90. >It was one of those things where a customer wanted them so Sun supplied. >Threads (i.e. LWP) had been in VMS for awhile, I don't know about >other commercial OSs. > >The funny thing is that although LWP VMS were indeed lightweight (say, >2 lbs. vs. 3 kg.), threads under unix were not, really (3g. vs. 4g.). > >Unix process creation is fast, and context switching on unix style >hardware is even better. LWPs were invented for OSs that were dogs, IMHO. > >There are two downsides to unix threads: > >1. It is hard to implement and test threads in an OS. Often they have >a very small user base so bugs can go undiscovered for a long time. > >2. Writing thread safe code is hard and takes practice. You should >figure on twice the coding time and three times the testing time to >make sure that your program will not bomb or worse. You should also >make sure that the programmers involved have written re-enterent code >before. Not true. Threaded code can be more succinct and easier to understand than non-threaded code. The first time I wrote a threaded program, I was hooked. What can get you are non re-entrant libraries and such, but developing actual threaded code is a piece of cake. If you do things right, you can often achieve a kind of clean modularity that is not possible with monolithic code. Threaded applications will be able to take advantage of SMP. Threaded numerical analysis code will experience a speedup from SMP, whereas monolithic code will be confined to one processor. Also, threading is important for the development of distributed systems. It is definitely a thing that needs to be standardized in UNIX. Every UNIX should support POSIX threading. There are many times when I would like to be able to use threading, or at *least* asynchronous I/O with signal notification, but cannot do so because of portability issues. Thus, I have to hack out a solution I know is not nearly as elegant as the one I had in mind. Having worked with OS code has changed the way I approach program design; I much more readily visualize a system as consisting of communicating processes, rather than just static code modules. Threading lets you do _real_ object oriented design, not the make-believe stuff that C++ programmers _think_ is object oriented. (No, even a well-disguised procedure call is _not_ message passing, guys! get it straight :) -- I got my degree from the U of NIX. Better dead than Redmond.