Experience With Processes and Monitors in Mesa

Size: px

Start display at page:

Download "Experience With Processes and Monitors in Mesa"

Aileen Morrison
5 years ago
Views:

1 Advanced Tpics in Cmputer Systems, CS262A Prf. Eric Brewer Experience With Prcesses and Mnitrs in Mesa I. Experience With Prcesses and Mnitrs in Mesa Fcus f this paper: light-weight prcesses (threads in tday s terminlgy) and hw they synchrnize with each ther. Histry: 2nd system; fllwed the Alt. planned t build a large system using many prgrammers. (Sme thughts abut cmmercializing.) advent f things like server machines and netwrking intrduced applicatins that are heavy users f cncurrency. Chse t build a single address space system: single user system, s prtectin nt an issue. (Safety was t cme frm the language.) wanted glbal resurce sharing. Large system, many prgrammers, many applicatins: Mdule-based prgramming with infrmatin hiding. Since they were starting frm scratch, they culd integrate the hardware, the runtime sftware, and the language with each ther. Prgramming mdel fr inter-prcess cmmunicatin: shared memry (mnitrs) vs. message passing. Needham & Lauer claimed the tw mdels are duals f each ther. Chse shared memry mdel because they thught they culd fit it int Mesa as a language cnstruct mre naturally. Hw t synchrnize prcesses? Nn-preemptive scheduler: tends t yield very delicate systems. Why? Have t knw whether r nt a yield might be called fr every prcedure yu call. Vilates infrmatin hiding. Prhibits multiprcessr systems. Need a separate preemptive mechanism fr I/O anyway. Can t d multiprgramming acrss page faults. Simple lcking (e.g. semaphres): t little structuring discipline, e.g. n guarantee that lcks will be released n every cde path; wanted smething that culd be integrated int a Mesa language cnstruct. 1 9/21/09

2 Chse preemptive scheduling f light-weight prcesses and mnitrs. Light-weight prcesses: easy frking and synchrnizatin shared address space fast perfrmance fr creatin, switching, and synchrnizatin; lw strage verhead. Mnitrs: mnitr lck (fr synchrnizatin) tied t mdule structure f the language: makes it clear what s being mnitred. language autmatically acquires and releases the lck. tied t a particular invariant, which helps users think abut the prgram cnditin variable (fr scheduling) Dangling references similar t thse f pinters. There are als language-based slutins that wuld prhibit these kinds f errrs, such as d-acrss, which is just a parallel cntrl structure. It eliminates dangling prcesses because the syntax defines the pint f the frk and the jin. Mnitrs (and Mesa in particular) led t several aspects f Java. Java s synchrnized Mnitrs external internal entry Java Synchrnized Objects public private synchrnized public synchrnized bjects are the bject-riented prgramming versin n mnitrs, and they are a better slutin than mnitred recrds. (Each instance has its wn lck rather than just each element f an array.) Changes made t design and implementatin issues encuntered: 3 types f prcedures in a mnitr mdule: entry (acquires and releases lck). internal (n lcking dne): can t be called frm utside the mdule. external (n lcking dne): externally callable. Why is this useful? - allws gruping f related things int a mdule. - allws ding sme f the wrk utside the mnitr lck. - allws cntrlled release and reacquisitin f mnitr lck. Ntify semantics: Cede lck t waking prcess: t many cntext switches. Why wuld this apprach be desirable? (Waiting prcess knws the cnditin it was waiting n is guaranteed t hld.) 2

3 Ntifier keeps lck, waking prcess gets put a frnt f mnitr queue. Desn t wrk in the presence f pririties. Ntifier keeps lck, wakes prcess with n guarantees => waking prcess must recheck its cnditin. What ther kinds f ntificatin des this apprach enable? Timeuts, bradcasts, abrts. Abrt: a nice request t abrt -- allws the target prcess t reach a wait r mnitr exit, and then it vluntarily abrts. N need t re-establish the invariant -- as cmpared t just killing the prcess utright! Deadlcks: Wait nly releases the lck f the current mnitr, nt any nested calling mnitrs. This is a general prblem with mdular systems and synchrnizatin: synchrnizatin requires glbal knwledge abut lcks, which vilates the infrmatin hiding paradigm f mdular prgramming. Why is mnitr deadlck less nerus than the yield prblem fr nn-preemptive schedulers? Want t generally insert as many yields as pssible t prvide increased cncurrency; nly use lcks when yu want t synchrnize. Yield bugs are difficult t find (symptms may appear far after the bgus yield) Basic deadlck rule: n recursin, direct r mutual Lck granularity: intrduced mnitred recrds s that the same mnitr cde culd handle multiple instances f smething in parallel. Interrupts: interrupt handler can t blck waiting t acquire a mnitr lck. Intrduced naked ntifies: ntifies dne withut hlding the mnitr lck. Had t wrry abut a timing race: the ntify culd ccur between a mnitr s cnditin check and its call n Wait. This a time f check t time f use (tctu, prnunced tck-t ) bug -- the cnditin f the test n lnger applies at the time f use. In particular, the sequence: 1) check fr waiters == false, 2) naked ntify, 3) g t sleep is a tctu bug. Added a wakeup-waiting flag t cnditin variables; naked ntify sets the wakeup waiting flag if the target is awake, and befre that prcess ges t sleep it checks this bit, and if set, resets it, and stays awake t check fr ntifies again. What happens in general with a message handlers that needs t acquire a lck? (use the interrupt t queue the task, and then acquire lcks in a prcess cntext instead) Pririty Inversin high-pririty prcesses may blck n lwer-pririty prcesses a slutin: temprarily increase the pririty f the hlder f the mnitr t that f the highest pririty blcked prcess (smewhat tricky -- what happens when that high-pririty prcess finishes with the mnitr? Yu have t knw the pririty f the next highest keep them srted r scan the list n exit) The Mars rver stalled due t this kind f bug and had t be debugged and fixed frm earth! Exceptins: must restre mnitr invariant as yu unwind the stack. What des Java d? (yu must use a sequence f try-finally blcks) The idea that yu can just kill a prcess and release the lcks is naive -- each lck prtects sme invariant that really needs t be restred befre yu can release the lck. Entry prcedures that have an exceptin, but n exceptin handler DO NOT release the mnitr lck. This ensures deadlck and a trip int the debugger, but at least it maintains the invariant. 3

4 Hints vs. Guarantees: Ntify is nly a hint. dn t have t wake up the right prcess, dn t have t change the ntifier if we slightly change the wait cnditin (the tw are decupled). easier t implement, because it s always OK t wake up t many prcesses. If we get lst, we culd even wake up everybdy (bradcast) Enables timeuts and abrts General Principle: use hints fr perfrmance that have little r better yet n effect n the crrectness. Inktmi uses hints fr fault tlerance: if the hint is wrng, things we ll timeut and we ll use a backup strategy perfrmance hit fr incrrect hint, but n errrs. Perfrmance: Cntext switch is very fast: 2 prcedure calls. Ended up nt mattering much fr perfrmance: - ran nly n uniprcessr systems. - cncurrency mstly used fr clean structuring purpses. Prcedure calls are slw: 30 instrs (RISC prc. calls are 10x faster). Due t heapallcated prcedure frames. Why did they d this? Didn t want t wrry abut clliding prcess stacks. Mental mdel was any prcedure call might be a frk : xfer was basic cntrl transfer primitive. Prcess creatin: ~ 1100 instrs. Gd enugh mst f the time. Fast-frk package implemented later that keeps arund a pl r available prcesses. 3 key features abut the paper: Describes the experiences designers had with designing, building and using a large system that aggressively relies n light-weight prcesses and mnitr facilities fr all its sftware cncurrency needs. Describes varius subtle issues f implementing a threads-with-mnitrs design in real life fr a large system. Discusses the perfrmance and verheads f varius primitives and three representative applicatins, but desn t give a big picture f hw imprtant varius things turned ut t be. Sme flaws: Glss ver hw hard it is t prgram with lcks and exceptins smetimes. (Nt clear if there are better ways). Perfrmance discussin desn t give the big picture. 4

5 A lessn: The light-weight threads-with-mnitrs prgramming paradigm can be used t successfully build large systems, but there are subtle pints that have t be crrect in the design and implementatin in rder t d s. 5

CS4500/5500 Operating Systems Synchronization

CS4500/5500 Operating Systems Synchronization Operating Systems Synchrnizatin Yanyan Zhuang Department f Cmputer Science http://www.cs.uccs.edu/~yzhuang UC. Clrad Springs Recap f the Last Class Multiprcessr scheduling Tw implementatins f the ready