Prentice Hall UNIX Systems Programming Communication Concurrency And Threads Jun 2003 ISBN 0130424110 pdf

  

• Un ix ™ Syst e m s Pr ogr a m m in g: Com m u n ica t ion , Con cu r r e n cy, a n d Th r e a ds

  By ,

  Publisher: Prent ice Hall PTR Pub Dat e: June 17, 2003

  I SBN: 0- 13- 042411- 0 Pages: 912 This com plet ely updat ed classic ( originally t it led Pract ical UNI X Program m ing) dem onst rat es how t o design com plex soft w are t o get t he m ost from t he UNI X operat ing syst em . UNI X

Syst em s Program m ing provides a clear and easy- t o- underst and int roduct ion t ot he essent ials of

UNI X program m ing. St art ing w it h short code snippet st hat illust rat e how t o use syst em calls, Robbins and Robbins m ovequickly t o hands- on proj ect s t hat help readers expand t heir skill levels. This pract ical guide t horoughly explores com m unicat ion, concurrency,and m ult it hreading. Know n for it s com prehensive and lucid explanat ions of com plicat ed t opics such as signals and concurrency, t he book feat ures pract ical exam ples, exercises, reusable code, and sim plified libraries for use in net w ork com m unicat ion applicat ions.

A self- cont ained reference t hat relies on t he lat est UNI X st andards,UNI X Syst em s Program m ing

provides t horough coverage of files, signals,sem aphores, POSI X t hreads, and client - server com m unicat ion. Thisedit ion feat ures all- new chapt ers on t he Web, UDP, and server perform ance. The sam ple m at erial has been t est ed ext ensively in t heclassroom .

  

  

• Un ix ™ Syst e m s Pr ogr a m m in g: Com m u n ica t ion , Con cu r r e n cy, a n d Th r e a ds

  By Publisher: Prent ice Hall PTR Pub Dat e: June 17, 2003

  I SBN: 0- 13- 042411- 0 Pages: 912

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

   Copyright Robbins, St even, 1947-

UNI X syst em s program m ing: com m unicat ion, concurrence, and t hreads / St even Robbins, Kay

Robbins p. cm .

  

Previously published under t he t it le: Pract ical UNI X Program m ing / Kay Robbins. Upper Saddle

River, NJ: Prent ice Hall, c1996.

  I SBN 0- 13- 0424110

1. UNI X ( Com put er file) 2. Operat ing syst em s ( Com put ers) I . Robiins, Kay A. I I . Robbins, Kay

A. Pract ical UNI X program m ing. I I I . Tit le

  Product ion Supervisor: Wil Mara Acquisit ions Edit or: Greg Doench Cover Design: Nina Scuderi and Talar Booruj y Cover Design Direct or: Jerry Vot t a Edit orial Assist ant : Brandt Kenna Market ing Manager: Dan DePasquale Manufact uring Manager: Alexis Heydt - Long © 2003 Pearson Educat ion, I nc.

  Publishing as Prent ice Hall Professional Technical Reference Upper Saddle River, New Jersey 07458 Prent ice Hall books are w idely used by corporat ions and governm ent agencies for t raining, m arket ing, and resale.

  

Pr e n t ice H a ll PTR offe r s e x ce lle n t discou n t s on t h is book w h e n or de r e d in qu a n t it y for

bu lk pu r ch a se s or spe cia l sa le s. For m or e in for m a t ion , ple a se con t a ct : U.S. Cor por a t e

a n d Gove r n m e n t Sa le s, 1 - 8 0 0 - 3 8 2 - 3 4 1 9 , . For sa le s

ou t side t h e U.S., ple a se con t a ct : I n t e r n a t ion a l Sa le s, 1 - 3 1 7 - 5 8 1 - 3 7 9 3 ,

  

Com pany and product nam es m ent ioned herein are t he t radem arks or regist ered t radem arks of

t heir respect ive ow ners. Allright s reserved. No part of t his book m ay be reproduced, in any form or by any m eans, w it hout perm ission in w rit ing from t he publisher. Print ed in t he Unit ed St at es of Am erica First Print ing Pearson Educat ion LTD. Pearson Educat ion Aust ralia PTY, Lim it ed Pearson Educat ion Singapore, Pt e. Lt d.

  Pearson Educat ion Nort h Asia Lt d. Pearson Educat ion Canada, Lt d Pearson Educat ión de Mexico, S.A. de C.V.

  Pearson Educat ion —Japan Pearson Educat ion Malaysia, Pt e. Lt d.

  Dedication To Nicole and Thom as

   About the Web Site

The w eb sit e offers addit ional resources for t he book, including all of

t he program s in dow nloadable form . These program s are freely available wit h no resrict ions

ot her t han acknow ledgem ent of t heir source. The sit e also has links t o sim ulat ors, t est ing t ools,

course m at erial prepared by t he aut hors, and an errat a list .

  

   Preface

UNI X Syst em s Program m ing: Com m unicat ion, Concurrency and Threads is t he second edit ion of

Pract ical UNI X Program m ing: A Guide t o Com m unicat ion, Concurrency and Mult it hreading, w hich w as published by Prent ice Hall in 1995. We changed t he t it le t o bet t er convey what t he book is about . Several t hings have changed, besides t he t it le, since t he last edit ion.

  The I nt ernet has becom e a dom inant aspect of com put ing and of societ y. Our privat e

inform at ion is online; our soft w are is under const ant at t ack. Never has it been so im port ant t o

w rit e correct code. I n t he new edit ion of t he book, we t ried t o produce code t hat correct ly

handles errors and special sit uat ions. We realized t hat saying handle all errors but giving code

exam ples w it h t he error handling om it t ed was not effect ive. Unfort unat ely, error handling m akes code m ore com plex. We have worked hard t o m ake t he code clear.

  Anot her im port ant developm ent since t he last edit ion is t he adopt ion of a Single UNI X Specificat ion, w hich w e refer t o as POSI X in t he book. We no longer have t o decide which

vendor's version of a library funct ion t o use—t here is an official version. We have done our best

t o com ply w it h t he st andard.

  The exercises and proj ect s m ake t his book unique. I n fact , t he book began as a proj ect w orkbook developed as part of a Nat ional Science Foundat ion Grant . I t becam e clear t o us, aft er prelim inary developm ent , t hat t he m at erial needed t o do t he proj ect s was scat t ered in m any places—oft en found in reference books t hat provide m any det ails but lit t le concept ual overview . The book has since evolved int o a self- cont ained reference t hat relies on t he lat est UNI X st andards.

  The book is organized int o four part s, each of which cont ains t opic chapt ers and proj ect chapt ers. A t opic chapt er covers t he specified m at erial in a work- along fashion. The t opic chapt ers have m any exam ples and short exercises of t he form " t ry t his" or " what happens if." The t opic chapt ers close w it h one or m ore exercise sect ions. The book provides program m ing exercises for m any fundam ent al concept s in process m anagem ent , concurrency and com m unicat ion. These program m ing exercises sat isfy t he sam e need as do laborat ory

experim ent s in a t radit ional science course. You m ust use t he concept s in pract ice t o have real

underst anding. Exercises are specified for st ep- by- st ep developm ent , and m any can be im plem ent ed in under 100 lines of code.

  The t able below sum m arizes t he organizat ion of t he book—t went y t wo chapt ers grouped int o

four part s. The fift een t opic chapt ers do not rely on t he eight proj ect chapt ers. You can skip t he

proj ect s on t he first pass t hrough t he book.

  Pa r t Topic Ch a pt e r # Pr oj e ct Ch a pt e r # Technology's I m pact

  1 Program s

  2 Processes in UNI X

  3

  I Fu n da m e n t a ls UNI X I / O

  14 POSI X I PC

  21 Server Perform ance

  20 I nt ernet Radio

  19 Connect ionless Com m un.

  18 WWW Redirect ion

  17 I V Com m u n ica t ion Connect ion- Orient ed Com m un.

  16 Virt ual Machine

  15 Producer Consum er

  13 Sem aphores

  4 Files and Direct ories

  12 Thread Synchronizat ion

  11 I I I Con cu r r e n cy POSI X Threads

  10 Cracking Shells

  9 Virt ual Tim ers

  8 Tim es and Tim ers

  7 I I Asyn ch r on ou s Eve n t s Signals

  6 The Token Ring

  5 UNI X Special Files

  22 Proj ect chapt ers int egrat e m at erial from several t opic chapt ers by developing a m ore ext ensive

applicat ion. The proj ect s w ork on t w o levels. I n addit ion t o illust rat ing t he program m ing ideas,

t he proj ect s lead t o underst anding of an advanced t opic relat ed t o t he applicat ion. These proj ect s are designed in st ages, and m ost full im plem ent at ions are a few hundred lines long. Since you don't have t o w rit e a large am ount of code, you can concent rat e on underst anding

concept s rat her t han debugging. To sim plify t he program m ing, we m ake libraries available for

net w ork com m unicat ion and logging of out put . For a professional program m er, t he exercises at

t he end of t he t opic chapt ers provide a m inim al hands- on int roduct ion t o t he m at erial. Typically, an inst ruct or using t his book in a course would select several exercises plus one of

t he m aj or proj ect s for im plem ent at ion during a sem est er course. Each proj ect has a num ber of

variat ions, so t he proj ect s can be used in m ult iple sem est ers.

There are m any pat hs t hrough t his book. The t opic chapt ers in Part I are prerequisit es for t he

rest of t he book. Readers can cover Part s I I t hrough I V in any order aft er t he t opic chapt ers of

  

Part I . The except ion is t he discussion at t he end of lat er chapt ers about int eract ions ( e.g., how

t hreads int eract w it h signals) .

  We have assum ed t hat you are a good C program m er t hough not necessarily a UNI X C

program m er. You should be fam iliar wit h C program m ing and basic dat a st ruct ures.

covers t he bare essent ials of program developm ent if you are new t o UNI X.

  This book includes synopsis boxes for t he st andard funct ions. The relevant st andards t hat specify t he funct ion appear in t he lower- right corner of t he synopsis box. A book like t his is never done, but w e had t o st op som ewhere. We welcom e your com m ent s

and suggest ions. You can send em ail t o us at We have done our best

t o produce an error- free book. How ever, should you be t he first t o report an error, we will grat efully acknow ledge you on t he book w eb sit e. I nform at ion on t he book is available on t he

WWW sit e All of t he code included in t he book can be downloaded

from t he WWW sit e.

  

   Acknowledgments We are very grat eful t o Mike Speciner and Bob Lynch for reading t he ent ire m anuscript and m aking m any useful suggest ions. We are especially grat eful t o Mary Lou Nohr for her careful

and int elligent copy- edit ing. We w ould also like t o express our appreciat ion t o Neal Wagner and

Radia Perlm an for t heir encouragem ent and suggest ions.

  We have t aught undergraduat e and graduat e operat ing syst em s courses from 1988 t o dat e ( 2003) , and m uch of t he m at erial in t he book has been developed as part of t eaching t hese courses. The st udent s in t hese courses have suffered t hrough draft s in various st ages of developm ent and have field- t est ed em erging proj ect s. Their program bugs, com m ent s, com plaint s, and suggest ions m ade t he book a lot bet t er and gave us insight int o how t hese

t opics int errelat e. Som e of t he st udent s who found errors in an early draft include Joseph Bell,

Carlos Cadenas, I gor Grinshpan, Jason Jendrusch and Jam es Manion. We would like t o acknow ledge t he Nat ional Science Foundat ion for providing support t hrough t he NSFI LI grant USE- 0950497 t o build a laborat ory so t hat we had t he opport unit y t o develop t he original

curriculum upon w hich t his book is based. NSF ( DUE- 975093, DUE- 9752165 and DUE- 0088769)

also support ed developm ent of t ools for explorat ion and analysis of OS concept s.

  We w ould like t o t hank Greg Doench, our edit or at Prent ice Hall, for guiding us t hrough t he process and William Mara our product ion edit or, for bringing t he book t o publicat ion. We

t ypeset t he book using LATEX2 , and we would like t o express our appreciat ion t o it s producers

for m aking t his soft w are freely available.

  Special t hanks go t o our fam ilies for t heir unfailing love and support and especially t o our children, Nicole and Thom as, w ho have dealt wit h t his arduous proj ect wit h ent husiasm and underst anding.

  

  

  Part I: Fundamentals

  

Chapter 1. Technology's Impact on Programs This chapt er int roduces t he ideas of com m unicat ion, concurrency and asynchronous operat ion

  at t he operat ing syst em level and at t he applicat ion level. Handling such program const ruct s

incorrect ly can lead t o failures w it h no apparent cause, even for input t hat previously seem ed

t o w ork perfect ly. Besides t heir added com plexit y, m any of t oday's applicat ions run for weeks

or m ont hs, so t hey m ust properly release resources t o avoid wast e ( so- called leaks of

resources) . Applicat ions m ust also cope wit h out rageously m alicious user input , and t hey m ust

recover from errors and cont inue running. The Port able Operat ing Syst em I nt erface ( POSI X)

st andard is an im port ant st ep t ow ard producing reliable applicat ions. Program m ers who writ e

for POSI X- com pliant syst em s no longer need t o cont end wit h sm all but crit ical variat ions in t he

behavior of library funct ions across plat form s. Most popular UNI X versions ( including Linux and

Mac OS X) are rapidly m oving t o support t he base POSI X st andard and various levels of it s ext ensions.

  Objectives _{● ●} Learn how an operat ing syst em m anages resources _● Experim ent w it h buffer overflows _● Explore concurrency and asynchronous behavior _● Use basic operat ing syst em s t erm inology Underst and t he serious im plicat ions of incorrect code

  

  

1.1 Terminology of Change

  Com put er pow er has increased exponent ially for nearly fift y years [ in m any areas including processor, m em ory and m ass- st orage capacit y, circuit densit y, hardware reliabilit y and I / O bandw idt h. The grow t h has cont inued in t he past decade, along wit h sophist icat ed inst ruct ion pipelines on single CPUs, placem ent of m ult iple CPUs on t he deskt op and an explosion in net w ork connect ivit y.

  The dram at ic increases in com m unicat ion and com put ing power have t riggered fundam ent al changes in com m ercial soft w are. _● Large dat abase and ot her business applicat ions, which form erly execut ed on a m ainfram e connect ed t o t erm inals, are now dist ribut ed over sm aller, less expensive _● m achines. Term inals have given w ay t o deskt op workst at ions wit h graphical user int erfaces and _{● At t he ot her end of t he spect rum , st andalone personal com put er applicat ions have} m ult im edia capabilit ies. evolved t o use net w ork com m unicat ion. For exam ple, a spreadsheet applicat ion is no longer an isolat ed program support ing a single user because an updat e of t he spreadsheet m ay cause an aut om at ic updat e of ot her linked applicat ions. These could _● graph t he dat a or perform sales proj ect ions.

Applicat ions such as cooperat ive edit ing, conferencing and com m on whit eboards

_● facilit at e group w ork and int eract ions.

Com put ing applicat ions are evolving t hrough sophist icat ed dat a sharing, realt im e

int eract ion, int elligent graphical user int erfaces and com plex dat a st ream s t hat include audio and video as w ell as t ext . These developm ent s in t echnology rely on com m unicat ion, concurrency and asynchronous operat ion w it hin soft w are applicat ions.

  Asynchronous operat ion occurs because m any com put er syst em event s happen at

unpredict able t im es and in an unpredict able order. For exam ple, a program m er cannot predict

t he exact t im e at w hich a print er at t ached t o a syst em needs dat a or ot her at t ent ion. Sim ilarly,

a program cannot ant icipat e t he exact t im e t hat t he user presses a key for input or int errupt s t he program . As a result , a program m ust work correct ly for all possible t im ings in order t o be correct . Unfort unat ely, t im ing errors are oft en hard t o repeat and m ay only occur once every m illion execut ions of a program .

  Concurrency is t he sharing of resources in t he sam e t im e fram e. When t w o program s execut e on t he sam e syst em so t hat t heir execut ion is int erleaved in t im e, t hey share processor resources. Program s can also share dat a, code and devices. The concurrent ent it ies can be t hreads of execut ion w it hin a single program or ot her abst ract obj ect s. Concurrency can occur in a syst em w it h a single CPU, m ult iple CPUs sharing t he sam e m em ory, or independent syst em s running over a net w ork. A m aj or j ob of a m odern operat ing syst em is t o m anage t he

concurrent operat ions of a com put er syst em and it s running applicat ions. However, concurrency

cont rol has also becom e an int egral part of applicat ions. Concurrent and asynchronous operat ions share t he sam e problem s—t hey cause bugs t hat are oft en hard t o reproduce and creat e unexpect ed side effect s.

  

Com m unicat ion is t he conveying of inform at ion by one ent it y t o anot her. Because of t he World

  

Wide Web and t he dom inance of net work applicat ions, m any program s m ust deal wit h I / O over

t he net w ork as w ell as from local devices such as disks. Net work com m unicat ion int roduces a

m yriad of new problem s result ing from unpredict able t im ings and t he possibilit y of undet ect ed

rem ot e failures.

  The rem ainder of t his chapt er describes sim plified exam ples of asynchronous operat ion, concurrency and com m unicat ion. The buffer overflow problem illust rat es how careless program m ing and lack of error checking can cause serious problem s and securit y breaches.

This chapt er also provides a brief overview of how operat ing syst em s work and sum m arizes t he

operat ing syst em st andards t hat are used in t he book.

  

  

1.2 Time and Speed

  Operat ing syst em s m anage syst em resources: processors, m em ory and I / O devices including

keyboards, m onit ors, print ers, m ouse devices, disks, t apes, CD- ROMs and net work int erfaces.

The convolut ed w ay operat ing syst em s appear t o w ork derives from t he charact erist ics of peripheral devices, part icularly t heir speed relat ive t o t he CPU or processor. list s

t ypical processor, m em ory and peripheral t im es in nanoseconds. The t hird colum n shows t hese

speeds slow ed dow n by a fact or of 2 billion t o give t he t im e scaled in hum an t erm s. The scaled

t im e of one operat ion per second is roughly t he rat e of t he old m echanical calculat ors from fift y

years ago.

  

Ta ble 1 .1 . Typica l t im e s for com pon e n t s of a com pu t e r syst e m . On e

• – 9
• – 6 n a n ose con d ( n s) is 1 0 se con ds, on e m icr ose con d ( s) is 1 0

  µ

• – 3

  se con ds, a n d on e m illise con d ( m s) is 1 0 se con ds.

  sca le d t im e in h u m a n t e r m s ( 2 billion it e m t im e t im e s slow e r )

  processor cycle 0.5 ns ( 2 GHz) 1 second cache access 1 ns ( 1 GHz) 2 seconds m em ory access 15 ns

  30 seconds cont ext sw it ch 5,000 ns ( 5 s) 167 m inut es µ disk access 7,000,000 ns ( 7 m s) 162 days quant um 100,000,000 ns ( 100 m s)

  6.3 years

Disk drives have im proved, but t heir rot at ing m echanical nat ure lim it s t heir perform ance. Disk

access t im es have not decreased exponent ially. The disparit y bet ween processor and disk access t im es cont inues t o grow ; as of 2003 t he rat io is roughly 1 t o 14,000,000 for a 2- GHz processor. The cit ed speeds are a m oving t arget , but t he t rend is t hat processor speeds are increasing exponent ially, causing an increasing perform ance gap bet ween processors and peripherals. The cont ext - sw it ch t im e is t he t im e it t akes t o swit ch from execut ing one process t o anot her. The quant um is roughly t he am ount of CPU t im e allocat ed t o a process before it has t o let anot her process run. I n a sense, a user at a keyboard is a peripheral device. A fast t ypist can t ype a keyst roke every 100 m illiseconds. This t im e is t he sam e order of m agnit ude as t he process scheduling quant um , and it is no coincidence t hat t hese num bers are com parable for int eract ive t im esharing syst em s.

  Ex e r cise 1 .1

  A m odem is a device t hat perm it s a com put er t o com m unicat e wit h anot her com put er over a phone line. A t ypical m odem is rat ed at 57,600 bps, where bps m eans " bit s per second."

Assum ing it t akes 8 bit s t o t ransm it a byt e, est im at e t he t im e needed for a 57,600 bps m odem

t o fill a com put er screen w it h 25 lines of 80 charact ers. Now consider a graphics display t hat

consist s of an array of 1024 by 768 pixels. Each pixel has a color value t hat can be one of 256

possible colors. Assum e such a pixel value can be t ransm it t ed by m odem in 8 bit s. What

com pression rat io is necessary for a 768- kbps DSL line t o fill a screen wit h graphics as fast as a

57,600- bps m odem can fill a screen wit h t ext ? An sw e r :

Table 1.2 com pares t he t im es. The t ext display has 80 x 25 = 2000 charact ers so 16,000 bit s

  

m ust be t ransm it t ed. The graphics display has 1024 x 768 = 786,432 pixels so 6,291,456 bit s

m ust be t ransm it t ed. The est im at es do not account for com pression or for com m unicat ion prot ocol overhead. A com pression rat io of about 29 is necessary!

Ta ble 1 .2 . Com pa r ison of t im e e st im a t e s for fillin g a scr e e n .

t im e n e e de d t o displa y m ode m t ype bit s pe r se con d t e x t gr a ph ics

  1979 t elephone m odem 300 1 m inut e 6 hours 1983 t elephone m odem 2,400 6 seconds 45 m inut es current t elephone m odem 57,600 0.28 seconds 109 seconds current DSL m odem 768,000 0.02 seconds 8 seconds

  

  

1.3 Multiprogramming and Time Sharing

  

Observe from t hat processes perform ing disk I / O do not use t he CPU very efficient ly:

0.5 nanoseconds versus 7 m illiseconds, or in hum an t erm s, 1 second versus 162 days. Because

of t he t im e disparit y, m ost m odern operat ing syst em s do m ult iprogram m ing. Mult iprogram m ing

m eans t hat m ore t han one process can be ready t o execut e. The operat ing syst em chooses one

of t hese ready processes for execut ion. When t hat process needs t o wait for a resource ( say, a

keyst roke or a disk access) , t he operat ing syst em saves all t he inform at ion needed t o resum e

t hat process w here it left off and chooses anot her ready process t o execut e. I t is sim ple t o see

how m ult iprogram m ing m ight be im plem ent ed. A resource request ( such as or )

  read write

  result s in an operat ing syst em request ( i.e., a syst em call) . A syst em call is a request t o t he

operat ing syst em for service t hat causes t he norm al CPU cycle t o be int errupt ed and cont rol t o

be given t o t he operat ing syst em . The operat ing syst em can t hen swit ch t o anot her process.

  Ex e r cise 1 .2 Explain how a disk I / O request m ight allow t he operat ing syst em t o run anot her process. An sw e r : Most devices are handled by t he operat ing syst em rat her t han by applicat ions. When an applicat ion execut es a disk read, t he call issues a request for t he operat ing syst em t o act ually perform t he operat ion. The operat ing syst em now has cont rol. I t can issue com m ands t o t he

disk cont roller t o begin ret rieving t he disk blocks request ed by t he applicat ion. However, since

t he disk ret rieval does not com plet e for a long t im e ( 162 days in relat ive t im e) , t he operat ing syst em put s t he applicat ion's process on a queue of processes t hat are wait ing for I / O t o com plet e and st art s anot her process t hat is ready t o run. Event ually, t he disk cont roller

int errupt s t he CPU inst ruct ion cycle when t he result s are available. At t hat t im e, t he operat ing

syst em regains cont rol and can choose whet her t o cont inue wit h t he current ly running process

or t o allow t he original process t o run. UNI X does t im esharing as w ell as m ult iprogram m ing. Tim esharing creat es t he illusion t hat several processes execut e sim ult aneously, even t hough t here m ay be only one physical CPU. On a single processor syst em , only one inst ruct ion from one process can be execut ing at any

  part icular t im e. Since t he hum an t im e scale is billions of t im es slower t han t hat of m odern

com put ers, t he operat ing syst em can rapidly swit ch bet ween processes t o give t he appearance

of several processes execut ing at t he sam e t im e.

  Consider t he follow ing analogy. Suppose a grocery st ore has several checkout count ers ( t he

processes) but only one checker ( t he CPU) . The checker checks one it em from a cust om er ( t he

inst ruct ion) and t hen does t he next it em for t hat sam e cust om er. Checking cont inues unt il a price check ( a resource request ) is needed. I nst ead of wait ing for t he price check and doing not hing, t he checker m oves t o anot her checkout count er and checks it em s from anot her

cust om er. The checker ( CPU) is alw ays busy as long as t here are cust om ers ( processes) ready

t o check out . This is m ult iprogram m ing. The checker is efficient , but cust om ers probably would

not w ant t o shop at such a st ore because of t he long wait when som eone has a large order wit h

no price checks ( a CPU- bound process) .

  

Now suppose t hat t he checker st art s a 10- second t im er and processes it em s for one cust om er for a m axim um of 10 seconds ( t he quant um ) . I f t he t im er expires, t he checker m oves t o anot her cust om er even if no price check is needed. This is t im esharing. I f t he checker is sufficient ly fast , t he sit uat ion is alm ost equivalent t o having one slower checker at each checkout st and. Consider m aking a video of such a checkout st and and playing it back at 100 t im es it s norm al speed. I t w ould look as if t he checker were handling several cust om ers sim ult aneously.

  Ex e r cise 1 .3

Suppose t hat t he checker can check one it em per second ( a one- second processor cycle t im e in

Table 1.1 ) . According t o t his t able, what would be t he m axim um t im e t he checker would spend

  w it h one cust om er before m oving t o a wait ing cust om er? An sw e r :

The t im e is t he quant um t hat is scaled in t he t able t o 6.3 years. A program m ay execut e billions

of inst ruct ions in a quant um —a bit m ore t han t he num ber of grocery it em s purchased by t he average cust om er.

I f t he t im e t o m ove from one cust om er t o anot her ( t he cont ext - swit ch t im e) is sm all com pared

w it h t he t im e bet w een sw it ches ( t he CPU burst t im e) , t he checker handles cust om ers efficient ly. Tim esharing w ast es processing cycles by swit ching bet ween cust om ers, but it has t he advant age of not w ast ing t he checker resources during a price check. Furt herm ore, cust om ers w it h sm all orders are not held in abeyance for long periods while wait ing for cust om ers w it h large orders.

  The analogy w ould be m ore realist ic if inst ead of several checkout count ers, t here were only one, w it h t he cust om ers crow ded around t he checker. To swit ch from cust om er A t o cust om er B, t he checker saves t he cont ent s of t he regist er t ape ( t he cont ext ) and rest ores it t o what it w as w hen it last processed cust om er B. The cont ext - swit ch t im e can be reduced if t he cash regist er has several t apes and can hold t he cont ent s of several cust om ers' orders

sim ult aneously. I n fact , som e com put er syst em s have special hardware t o hold m any cont ext s

at t he sam e t im e.

  Mult iprocessor syst em s have several processors accessing a shared m em ory. I n t he checkout analogy for a m ult iprocessor syst em , each cust om er has an individual regist er t ape and m ult iple checkers rove t he checkout st ands working on t he orders for unserved cust om ers.

  Many grocery st ores have packers w ho do t his.

  

  

1.4 Concurrency at the Applications Level Concurrency occurs at t he hardw are level because m ult iple devices operat e at t he sam e t im e.

  

Processors have int ernal parallelism and work on several inst ruct ions sim ult aneously, syst em s

have m ult iple processors, and syst em s int eract t hrough net work com m unicat ion. Concurrency

is visible at t he applicat ions level in signal handling, in t he overlap of I / O and processing, in com m unicat ion, and in t he sharing of resources bet w een processes or am ong t hreads in t he sam e process. This sect ion provides an overview of concurrency and asynchronous operat ion.

  1.4.1 Interrupts The execut ion of a single inst ruct ion in a program at t he convent ional m achine level is t he result of t he processor inst ruct ion cycle. During norm al execut ion of it s inst ruct ion cycle, a processor ret rieves an address from t he program count er and execut es t he inst ruct ion at t hat address. ( Modern processors have int ernal parallelism such as pipelines t o reduce execut ion t im e, but t his discussion does not consider t hat com plicat ion.) Concurrency arises at t he

convent ional m achine level because a peripheral device can generat e an elect rical signal, called

an int errupt , t o set a hardw are flag wit hin t he processor. The det ect ion of an int errupt is part of

t he inst ruct ion cycle it self. On each inst ruct ion cycle, t he processor checks hardware flags t o see if any peripheral devices need at t ent ion. I f t he processor det ect s t hat an int errupt has occurred, it saves t he current value of t he program count er and loads a new value t hat is t he address of a special funct ion called an int errupt service rout ine or int errupt handler. Aft er finishing t he int errupt service rout ine, t he processor m ust be able t o resum e execut ion of t he previous inst ruct ion w here it left off. An event is asynchronous t o an ent it y if t he t im e at which it occurs is not det erm ined by t hat ent it y. The int errupt s generat ed by ext ernal hardware devices are generally asynchronous t o program s execut ing on t he syst em . The int errupt s do not always occur at t he sam e point in a program 's execut ion, but a program should give a correct result regardless of where it is int errupt ed. I n cont rast , an error event such as division by zero is synchronous in t he sense t hat it alw ays occurs during t he execut ion of a part icular inst ruct ion if t he sam e dat a is present ed t o t he inst ruct ion. Alt hough t he int errupt service rout ine m ay be part of t he program t hat is int errupt ed, t he processing of an int errupt service rout ine is a dist inct ent it y wit h respect t o concurrency. Operat ing- syst em rout ines called device drivers usually handle t he int errupt s generat ed by peripheral devices. These drivers t hen not ify t he relevant processes, t hrough a soft ware m echanism such as a signal, t hat an event has occurred.

Operat ing syst em s also use int errupt s t o im plem ent t im esharing. Most m achines have a device

called a t im er t hat can generat e an int errupt aft er a specified int erval of t im e. To execut e a

user program , t he operat ing syst em st art s t he t im er before set t ing t he program count er. When

t he t im er expires, it generat es an int errupt t hat causes t he CPU t o execut e t he t im er int errupt

service rout ine. The int errupt service rout ine writ es t he address of t he operat ing syst em code int o t he program count er, and t he operat ing syst em is back in cont rol. When a process loses t he CPU in t he m anner j ust described, it s quant um is said t o have expired. The operat ing

syst em put s t he process in a queue of processes t hat are ready t o run. The process wait s t here

for anot her t urn t o execut e.

  1.4.2 Signals

  A signal is a soft w are not ificat ion of an event . Oft en, a signal is a response of t he operat ing

syst em t o an int errupt ( a hardw are event ) . For exam ple, a keyst roke such as Ct rl- C generat es

an int errupt for t he device driver handling t he keyboard. The driver recognizes t he charact er as

t he int errupt charact er and not ifies t he processes t hat are associat ed wit h t his t erm inal by sending a signal. The operat ing syst em m ay also send a signal t o a process t o not ify it of a com plet ed I / O operat ion or an error.

  A signal is generat ed w hen t he event t hat causes t he signal occurs. Signals can be generat ed eit her synchronously or asynchronously. A signal is generat ed synchronously if it is generat ed by t he process or t hread t hat receives it . The execut ion of an illegal inst ruct ion or a divide- by-

zero m ay generat e a synchronous signal. A Ct rl- C on t he keyboard generat es an asynchronous

signal. Signals ( ) .

  

A process cat ches a signal w hen it execut es a handler for t he signal. A program t hat cat ches a

signal has at least t w o concurrent part s, t he m ain program and t he signal handler. Pot ent ial concurrency rest rict s w hat can be done inside a signal handler ( . I f t he signal handler m odifies ext ernal variables t hat t he program can m odify elsewhere, t hen proper execut ion m ay require t hat t hose variables be prot ect ed.

  1.4.3 Input and output A challenge for operat ing syst em s is t o coordinat e resources t hat have great ly differing

charact erist ic access t im es. The processor can perform m illions of operat ions on behalf of ot her

processes w hile a program w ait s for a disk access t o com plet e. Alt ernat ively, t he process can

avoid blocking by using asynchronous I / O or dedicat ed t hreads inst ead of ordinary blocking I / O.

The t radeoff is bet w een t he addit ional perform ance and t he ext ra program m ing overhead in using t hese m echanism s.

  A sim ilar problem occurs w hen an applicat ion m onit ors t wo or m ore input channels such as

input from different sources on a net work. I f st andard blocking I / O is used, an applicat ion t hat

is blocked w ait ing for input from one source is not able t o respond if input from anot her source

becom es available.

  1.4.4 Processes, threads and the sharing of resources A t radit ional m et hod for achieving concurrent execut ion in UNI X is for t he user t o creat e

m ult iple processes by calling t he funct ion. The processes usually need t o coordinat e t heir

  fork

  operat ion in som e w ay. I n t he sim plest inst ance t hey m ay only need t o coordinat e t heir t erm inat ion. Even t he t erm inat ion problem is m ore difficult t han it m ight seem . addresses process st ruct ure and m anagem ent and int roduces t he UNI X , and

  fork exec wait syst em calls.

  Processes t hat have a com m on ancest or can com m unicat e t hrough pipes ( ) .

Processes w it hout a com m on ancest or can com m unicat e by signals ( . execut es, t he CPU uses t he program count er t o det erm ine which inst ruct ion t o execut e next .

The result ing st ream of inst ruct ions is called t he program 's t hread of execut ion. I t is t he flow of

cont rol for t he process. I f t w o dist inct t hreads of execut ion share a resource wit hin a t im e

fram e, care m ust be t aken t hat t hese t hreads do not int erfere wit h each ot her. Mult iprocessor

syst em s expand t he opport unit y for concurrency and sharing am ong applicat ions and wit hin applicat ions. When a m ult it hreaded applicat ion has m ore t han one t hread of execut ion concurrent ly act ive on a m ult iprocessor syst em , m ult iple inst ruct ions from t he sam e process m ay be execut ed at t he sam e t im e.

  Unt il recent ly t here has not been a st andard for using t hreads, and each vendor's t hread package behaved different ly. A t hread st andard has now been incorporat ed int o t he POSI X st andard. discuss t his new st andard.

  1.4.5 Multiple processors with shared memory How m any CPUs does a t ypical hom e com put er have? I f you t hink t he answer is one, t hink again. I n early m achines, t he m ain CPU handled m ost of t he decision m aking. As m achine

design evolved, I / O becam e m ore com plicat ed and placed m ore dem ands on t he CPU. One way

of enhancing t he perform ance of a syst em is t o det erm ine which com ponent s are t he

bot t lenecks and t hen im prove or replicat e t hese com ponent s. The m ain I / O cont rollers such as

t he video cont roller and disk cont roller t ook over som e of t he processing relat ed t o t hese

peripherals, relieving t he CPU of t his burden. I n m odern m achines, t hese cont rollers and ot her

I / O cont rollers have t heir ow n special purpose CPUs.

  What if aft er all t his auxiliary processing has been offloaded, t he CPU is st ill t he bot t leneck? There are t w o approaches t o im proving t he perform ance. Adm iral Grace Murray Hopper, a

pioneer in com put er soft w are, oft en com pared com put ing t o t he way fields were plowed in t he

pioneer days: " I f one ox could not do t he j ob, t hey did not t ry t o grow a bigger ox, but used

t w o oxen." I t w as usually cheaper t o add anot her processor or t wo t han t o increase t he speed

of a single processor. Som e problem s do not lend t hem selves t o j ust increasing t he num ber of

processors indefinit ely. Seym our Cray, a pioneer in com put er hardware, is report ed t o have said, " I f you w ere plow ing a field, w hich would you rat her use? Tw o st rong oxen or 1024 chickens?"

The opt im al t radeoff bet w een m ore CPUs and bet t er CPUs depends on several fact ors, including

t he t ype of problem t o be solved and t he cost of each solut ion. Machines wit h m ult iple CPUs have already m igrat ed t o t he deskt op and are likely t o becom e m ore com m on as prices drop. Concurrency issues at t he applicat ion level are slight ly different when t here are m ult iple processors, but t he m et hods discussed in t his book are equally applicable in a m ult iprocessor environm ent .

  1.4.6 The network as the computer Anot her im port ant t rend is t he dist ribut ion of com put at ion over a net work. Concurrency and com m unicat ion m eet t o form new applicat ions. The m ost widely used m odel of dist ribut ed com put at ion is t he client - server m odel. The basic ent it ies in t his m odel are server processes t hat m anage resources, and client processes t hat require access t o shared resources. ( A process can be bot h a server and a client .) A client process shares a resource by sending a request t o a server. The server perform s t he request on behalf of t he client and sends a reply t o t he client . Exam ples of applicat ions based on t he client - server m odel include file t ransfer ( ) , elect ronic m ail, file servers and t he World Wide Web. Developm ent of client - server

  ftp applicat ions requires an underst anding of concurrency and com m unicat ion. The obj ect - based m odel is anot her m odel for dist ribut ed com put at ion. Each resource in t he syst em is view ed as an obj ect w it h a m essage- handling int erface, allowing all resources t o be accessed in a uniform w ay. The obj ect - based m odel allows for cont rolled increm ent al developm ent and code reuse. Obj ect fram eworks define int eract ions bet ween code m odules, and t he obj ect m odel nat urally expresses not ions of prot ect ion. Many of t he experim ent al dist ribut ed operat ing syst em s such as Argus [ , Clouds [

   are obj ect based. Obj ect - based m odels require obj ect m anagers t o t rack t he locat ion of t he obj ect s in t he syst em .

  An alt ernat ive t o a t ruly dist ribut ed operat ing syst em is t o provide applicat ion layers t hat run

on t op of com m on operat ing syst em s t o exploit parallelism on t he net work. The Parallel Virt ual

Machine ( PVM) and it s successor, Message Passing I nt erface ( MPI ) , are soft ware libraries [ ,

t hat allow a collect ion of het erogeneous workst at ions t o funct ion as a parallel com put er for

solving large com put at ional problem s. PVM m anages and m onit ors t asks t hat are dist ribut ed on

w orkst at ions across t he net w ork. develops a dispat cher for a sim plified version of PVM. CORBA ( Com m on Obj ect Request Broker Archit ect ure) is anot her t ype of soft ware layer t hat provides an obj ect - orient ed int erface t o a set of generic services in a het erogeneous dist ribut ed environm ent [ ] .

  

  

1.5 Security and Fault Tolerance

  The 1950s and early 1960s brought bat ch processing, and t he m id- t o- lat e 1960s saw deploym ent of operat ing syst em s t hat support ed m ult iprogram m ing. Tim e- sharing and real-

t im e program m ing gained popularit y in t he 1970s. During t he 1980s, parallel processing m oved

from t he supercom put er arena t o t he deskt op. The 1990s was t he decade of t he net work—wit h

t he w idespread use of dist ribut ed processing, em ail and t he World Wide Web. The 2000s appears t o be t he decade of securit y and fault - t olerance. The rapid com put erizat ion and t he dist ribut ion of crit ical infrast ruct ure ( banking, t ransport at ion, com m unicat ion, m edicine and governm ent ) over net w orks has exposed enorm ous vulnerabilit ies. We have com e t o rely on

program s t hat w ere not adequat ely designed or t est ed for a concurrent environm ent , writ t en by

program m ers w ho m ay not have underst ood t he im plicat ions of incorrect ly working program s.

The liabilit y disclaim ers dist ribut ed wit h m ost soft ware at t em pt s t o absolve t he m anufact urers of responsibilit y for dam age—soft w are is dist ribut ed as is.