Plan for dagen Kap. 11: Resource control (utvalg) Hva trenger vi av egenskaper? Hvordan unngår vi vranglåser? Ikke pensum! Kap. 11.4 (The requeue facility) Kap 14 (Distributed Systems) Kap 14 Distributed systems (utvalg) Resource Management Kontekst: Ønsket basis-funksjonalitet: allocate & free aktiv: Server passiv: Protected Resource Beskyttelse: Trenger bare isolation... Må unngå vranglås og utsulting, og håndtere feil. Har: semaforer, monitorer, guards etc. (kap. skiller imellom condition & avoidance synkronisering) Men: vi vil ha bedre styring og mer funksjonalitet: Bloom (1979) Egentlig: Kriterier for evaluering av synkroniseringsprimitiver Her: Overskrifter på hva vi ønsker fra vår resource manager. (tatt ut historie, lagt til prioritet)
Request Type: Bloom kriterier I lese kontra skrive vi ønsker å angi prioritet/fordeling Vi kan tillate mange samtidige lesere Alle prosedyrene i en monitor kan ses på som en request type til resursen Request order FIFO Prioritet Bloom kriterier II Ok, disse lar seg greit kombinere på intuitivt vis, men hva når vi blander service types opp i det? Allerede her faller standard semaforbeskyttelse Eksempel på lesing/skriving er gitt tidligere... Løsning: Eksplisitt håndtering av køen kan ikke stole på språk/scheduler/os (først register, så action ) Bloom kriterier III Server state (+ history) Det trivielle tilfelle: er resursen ledig? Løses enkelt ved guards, eller posisjonering av accept'en Bloom kriterier IV Request Parameters Jeg trenger 3kb... Jeg trenger resurs A og resurs C... Boken skisserer både conditional & avoidance løsninger Kommer fort opp i ryggsekkproblembetraktninger... planleggingsproblemer Vranglåsunngåelse Kan vi leve med at språk/scheduler/os vedlikeholder køen av ventende prosesser?
Requester Priority Bloom kriterier V Det er en selvfølge at en høyprioritetsprosess får kjøre hvis den er kjørbar... Er det en selvfølge at den står først i køen ved resursallokering? Svaret er Nei... men i Java, POSIX & Ada kan du be om det! Requeue (ikke pensum) Boken sammenligner avoidance (v. guards) & conditional synchronization: avoidance gir penere & enklere kode, men mangler litt utrykkskraft (blir drevet til to-fase allokering oftere) Ada retter på dette ved requeue mekanismen... Stor konklusjon (dvs. Sverres konklusjon:) Håndter resurser, køer, synkronisering eksplisitt Ikke insister på å bruke språkets mekanismer/scheduleren/os'et til å løse dine spesielle problemer. monitorer, etc. er og blir bare grunnleggende mekanismer Vranglåser: Alle fire kriterier er nødvendig for å få vranglås: Mutual Exclusion hold & wait No preemption circular wait Hva kan vi gjøre? Prevention (unngå minst en av de 4) avoidance (smart schedulering/allokering) detection & recovery
Mutual Exclusion Deadlock prevention mange lesere samtidig... Deadlock prevention II Ellers lite å gjøre. hold & wait Slå sammen alle mulige ventesituasjoner øverst vil dermed aldri vente med allokerte resuser No preemption Bruke feilhåndteringsteknikker for å ta fra en prosess resursene. circular wait En globalt akseptert rekkefølge av resursallokering Analyse bevise fravær av deadlocks. Low-level synchronization primitives are extremely difficult to examine this way CSP (f.eks. occam) ok. Deadlock avoidance Resource Manager som nekter allokeringer som kan føre til deadlocks. (skiller imellom trygge og utrygge tilstander.) Bankers algorithm Må kjenne bruksmønster. With more than one resource type the algorithm becomes more complicated priority ceiling Deadlock detection and recovery Resource dependency graph Hvem eier resursene, hvem venter på hva. En allokering som gir syklisk graf gir feil. Evt. i en annen av prosessene? Rettferdighet etc. TimeOut?