Betriebssysteme - Tamdhu www root

Betriebssysteme
Winter2016
Betriebssysteme
(c)PeterSturm,UniTrier
1
Betriebssysteme
Winter2016
Organisatorisches
• VorlesungDienstags,10.00bis11.30,F55
• Master-Veranstaltung
• Übung
• Klausur
– 21.2.2017
– Bonussystem?
• Informationen
– http://tamdhu.uni-trier.de/Asysob
– Stud.IP
VONMONOLITHENUND
MIKROKERNEN
(c)PeterSturm,UniTrier
2
Betriebssysteme
Winter2016
WaytoAccessOSFunctionality
• Libraryfunctions
– Classicalprocedurecall
– Staticanddynamiclinking
Applications
• SystemCalls
– Theactualfunctionsofthe
operatingsystems
– Wrappersletsystemcalls
looklikelibraryfunctions
– InsomeOS,systemcallsare
notdirectlyaccessibleby
applications(evenaswrappers)
Operating System
Libraries
System Call Wrapper
System Calls
SystemCall
• Theonlylegitimateaccesstotheoperatingsystemkernel
• Systemcalls=softwareinterrupt
– Codeexecutionstartsatdefinedaddress
ofassociatedinterruptserviceroutine
– Switchtoprivilegedmode
– Switchtokernelstack
System Call
Illicit
Calls
Protective Barrier
Operating System Sanctum J
(c)PeterSturm,UniTrier
3
Betriebssysteme
Winter2016
SupervisorMode&UserMode
• ModernoperatingsystemsrequireCPUtodifferbetween
– Supervisormode
• Everyinstructioncanbeexecuted,
includingconfiguringMMUetc.
• Accesstoallmemorylocations
User
Mode
– Usermode
• Sensibleinstructionsarenotallowed
(MMU,interrupthandling,…)
• Restrictedmemoryaccess
(MMU)
• OnlyOSallowedtorunin
supervisormode
Hardware
Interrupt
Software
Interrupt
Supervisor
Mode
SwitchOn
EverythingIsInsideTheKernel
• Threadissuingsystemcall„stays“insidekerneluntilcallis
completed
• Allrequiredfunctionality
mustbeinsidekernel
• Context-switchin
caseofblocking
• Monolith
(c)PeterSturm,UniTrier
OS Kernel
System Call
4
Betriebssysteme
Winter2016
…orISS
NexttoNothingInsideKernel
Microkernel
Client
Context
Switch
(c)PeterSturm,UniTrier
Server 1
Server 2
Server 3
Server 4
5
Betriebssysteme
Winter2016
Microkernel
• Implementsveryfewessentialabstractions
– Communicationprimitivestocrossaddressspaces
– Protection
– Interruptpreprocessinganddelivery
• Goal:Nosingleapplicationcanmonopolizeresources
• Dislocationofallremainingoperatingsystemfunctionality
intousermodeserver
–
–
–
–
Fileserver
Communicationserver
Graphicsserver
…
• Fromascientificpointofviewthemostattractivesolution
Comparison
Monolith
MicrokernelandServer
•
•
Pro
– Fast
•
(c)PeterSturm,UniTrier
– Goodarchitectureandstructure
possible
– Easiertoextend
– Easiertoadapt
– Debuggingofserverswithuser
modetools
Contra
– Keepingagoodarchitectureand
structurerequiresalotofselfdiscipline
– Noisolationbetweendifferent
partsofkernel
– Hardtoextend
– Complextoadapt
Pro
•
Contra
– Slow
(toomanycontextswitches)
6
Betriebssysteme
Winter2016
AcceleratingMicrokernels
•
Sensibleand/ortime-criticalservers
returnintokernel
– Microkernelbecomes„still
structured“monolith
•
Server
1
Server
n
Realization
– AdditionallinkingstepreplacesIPC
withfunctionscalls
– Ofcourse,noprotectionanymore
•
Appliedinmostmodernan
microkernel-basedoperating
systems
– MACH
– NTandsubsequentsystems
Microkernel
ImprovingMonoliths
• ExampleLinux
– Introductionofamoduleconcept
– Partsofoperatingsystems(especiallydrivers)willbeloadedon
demand
– Mostmodulescanbeunloadedagain
• Execution,testing,anddebuggingstillnotpossibleinuser
mode
• Stillnoprotection
Module1
Module2
Module3
Modulen
Monolith
(c)PeterSturm,UniTrier
7
Betriebssysteme
Winter2016
LINUX
Linux
SystemCallInterface
Process
Management
Architecture
Dependent
Code
(c)PeterSturm,UniTrier
Memory
Management
Memory
Manager
Filesystems
Filesystem
Types
Block
Devices
Device
Control
Character
Devices
Networking
Network
Subsystem
IF
Drivers
8
Betriebssysteme
Winter2016
History
• ArchetypeMINIX
– Minimal-UNIXforteachingpurposes
– A.Tanenbaum,Amsterdam
• LinusTorvaldsimplementshisown
system
• Firstappearance:comp.os.minix,
29.3.1991
„Helloeverybody,
I‘vehadminixforaweeknow,andhaveupgradedto386-minix(nice),
anddulydownloadedgccforminix.Yes,itworks– but…optimizing
isnt‘tworking,givingerrormessage[…].Isthisnormal?“
Aminixclonewasborn
„Helloeverybodyoutthereusingminix–
I‘mdoinga(free)operatingsystem(justahobby,won‘tbebig
andprofessionallikegnu)for386(486)ATclones.Thishas
beenbrewingsinceApril,andisstartingtogetready.I‘dlike
anyfeedbackonthingspeoplelike/dislikeinminx,asmyOS
resemblesitsomewhat(samephyiscallayoutofthefilesystem(duetopracticalreasons)amongotherthings).
…I‘llgetsomethingpracticalwithinafewmonths,andi‘dlike
toknowwhatfeaturesmostpeoplewouldwant.Any
suggestionsarewelcome,butiwon‘tpromiseI‘llimplement
them:-)“
(c)PeterSturm,UniTrier
9
Betriebssysteme
Winter2016
Chronology
•
Version0.01,September1991
•
Version0.11,December1991
– 0.11+VMoverchristmas
•
Version0.12,January1992
•
Version0.95,March1992
•
Weareapproachingversion1
•
Version1.0,13.March1994
– Increasingnumberofinterestedpeople
– QuarrelonOSarchitecturewithA.Tanenbaum(Linuxisobsolete)
– 0.95a,0.95a.1,0.95c,0.95c+,pre0.96,0.96a(Mai1992),0.96b,0.96b.2,0.98,
0.98.2,0.99,0.99.13,0.99.13k,
Linuxisobsolete(1)
• Tanenbaum
„IwasintheU.S.foracoupleofweeks,
soihaven‘tcommentedmuchonLINUX
(notthatiwouldhavesaidmuchhadi
beenaround),butforwhatitisworth,
ihaveacoupleofcommentsnow.
Asmostofyouknow,formeMINIXisa
hobby,somethingthatidointheevening
whenigetboredwritingbooksandthere
arenomajorwars,revolutions,andsenate
hearingsbeingtelevisedliveonCNN.Myrealjobisaprofessorand
researcherintheareaofoperatingsystems.
Asaresultofmyoccupation,IthinkIknowabitaboutwhere
operatingsystemsaregoinginthenextdecadeorso.Twoaspects
standout[kernelarchitectureandportability].
[…]“
(c)PeterSturm,UniTrier
10
Betriebssysteme
Winter2016
Linuxisobsolete(2)
• Tanenbaum(contd.)
„WhileIcouldgointoalongstoryhereabouttherelativemeritsofthe
twodesigns,sufficetosaythatamongthepeoplewhoactuallydesign
operatingsystems,thedebateisessentiallyover.Microkernelshave
won.
LINUXisamonolithicstylesystem.Thisisagiantstepbackintothe
1970s.Thatisliketakinganexisting,workingCprogramandrewriting
itinBASIC.
IthinkitisagrosserrottodesignanOSforanyspecificarchitecture,
sincethatisnotgoingtobearoundallthatlong.MINIXwasdesigned
tobereasonablyportable,andhasbeenportedfromIntellinetothe
680x0(Atari,Amiga,Macintosh),SPARC,andNS32016.LINUXistied
fairlycloselytothe80x86.Notthewaytogo.“
Linuxisobsolete(3)
• Torvaldsreply
„Well,withasubjectlikethis,I‘mafraidI‘llhavetoreply.Apologiesto
minix-userswhohaveheardenoughaboutlinuxanyway.I‘dlinketobe
abletojust‚ignorethebait,‘but…Timeforsomeseriousflamefesting!
[…]Lookatwhomakesmoneyoffminix,andwhogiveslinuxoutfor
free.Thentalkabouthobbies.Makeminixfreelyavailable,andoneof
mybiggestgripeswithitwilldisappear.
[…](BezugnehmendaufTanenbaumsBeruf)That‘sonehellofgood
excuseforsomeofthebraindamagesofminix.Icanonlyhope(and
assume)thatAmoebadoesn‘tsucklikeminixdoes.“
(c)PeterSturm,UniTrier
11
Betriebssysteme
Winter2016
Linuxisobsolete(4)
• Torvaldsreply(contd)
„PS.Iapologizeforsometimessoundingtooharsh:minixisnice
enoughifyouhavenothingelse.Amoebamightbeniceifyouhave510spare386‘slyingaround,butIcertainlydon‘t.Idon‘tusuallyget
intoflames,butI‘mtouchywhenitcomestolinux:)“
Linuxisobsolete(5)
• Torvaldsemailnextday
„Iwrote:
Well,withasubjectlikethis,I’mafraidI’llhavetoreply.
AndreplyIdid,withcompleteabandon,andnothoughtforgoodtaste
andnetiquette.Apologiesto[AndrewTanenbaum],andthankstoJohn
Nallforafriendy“that’snothowit’sdone”letter.Ioverreacted,and
amnowcomposinga(muchlessacerbic)personalletterto[Andrew
Tanenbaum].Hopenobodywasturnedawayfromlinuxduetoitbeing
(a)possiblyobsolete(Istillthinkthat’snotthecase,althoughsomeof
thecriticismsarevalid)and(b)writtenbyahothead:-)
Linus“myfirst,andhopefullylastflamefest”Torvalds”
(c)PeterSturm,UniTrier
12
Betriebssysteme
Winter2016
Linuxisobsolete(6)
• Wisewordsbysomebodyelse
„Manyifnotmostofthesoftwareweusisprobablyobsolete
accordingtothelatestdesigncriteria.Mostuserscouldprobablycare
lessiftheinternalsoftheoperatingsystemtheyuseisobsolete.They
arerightlymoreinterestedinistperformanceandcapabilitiesatthe
userlevel.
Iwouldgenerallyagreethemicrokernelsareprobablythewaveofthe
future.However,itisinmyopinioneasiertoimplementamonolithic
kernel.Itisalsoeasierforittoturnintoamessinahurryasitis
modified.
Regards,
Ken”
• KenThompson,„Inventor“ofUNIX
Linuxisobsolete(7)
• Thefightisover
• Tanenbaum
„Istillmaintainthepointthatdesigningamonolithickernelin1991is
afundamentalerror.Bethankfulyourarenotmystudent.Youwould
notgetahighgradeforsuchadesign:-)
[…]WritinganewOSonlyforthe386in1991getyouyoursecond‘F’
forthisterm.Butifyoudorealwellonthefinalexam,youcanstillpass
thecourse.”
• Torvald
„Well,Iprobablywon‘tgettoogoodgradesevenwithoutyou:Ihadan
argument(completelyunrelated– notevenpertainingtoOS‘s)with
thepersonhereattheuniversitythatteachesOSdesign.Iwonder
whenI‘lllearn:)
(c)PeterSturm,UniTrier
13
Betriebssysteme
Winter2016
THEUNIXROOTS
Inthebeginning…
• 1969:FirstUNIXversion(BellLabs)
– „Private“researchprojectbyKenThompson„touseanotherwiseidle
PDP-7“
– DennisRichie:Cprogramminglanguage
– Sourcesavailabletouniversitiesfromtheverybeginning
• Predecessors
– MULTICS:AmbitiousgoalatBellLabswasarchetypeformanyofthe
centralabstractionssuchasfilesystem,shell,etc.
– CTSS(MIT)
– GENIE(Berkeley):fork()
(c)PeterSturm,UniTrier
14
Betriebssysteme
Winter2016
DennisRitchie
PDP-11
KenThompson
1972
TheUNIXWay
• UNIXwasprogrammedwithhigh-levelprogramminglanguage
– TriumphalprocessionforprogramminglanguageC
– About3%assembleronly
• UNIXwasdistributedassources
– AT&T(BellLabs)hadnocommericalinterest(atfirst)
• UNIXfeaturedpropertesonlymuchlargerandmore
expensivesystemsofferedatthistime
• UNIXprovidesmanyelementaryfunctionsthatcanbe
combinedinverydifferentways(synergy)
– forkandpipes
(c)PeterSturm,UniTrier
15
Betriebssysteme
Winter2016
ImportantUNIXfamilies
• FirstEditionuptoTenthEdition,Plan9
– TheofficialBellLabsbranch
– Plan9(4theditionavailablesince2003)
• BSDbranch
– Advancementsinanacademicenvironment
• SystemV
– Advancementsinacommericalenvironment
• SunOS/Solaris
• Linux
BSDfamily
FirstEdition
SixthEdition
1BSD
• Earlybranchinacademia
– UniversityofBerkeley,SanDiego
2BSD
• IntegrationofTCP/IP
protocolstack
3BSD
4.0BSD
4.1BSD
4.2BSD
4.3BSD
Tahoe
NET/1
Reno
NET/2
– ARPANET
– SocketAPI
– TCPvariants(Reno,Tahoe,Vegas,…)
• Licensedifficulty
– Severalapproachestoprovide
license/freeversion(Litex)
4.4BSD
• FreeBSD
2.11BSD
BSDI1
4.4BSD
Lite1
FreeBSD
2.0
(c)PeterSturm,UniTrier
2.8BSD
4.4BSD
Lite2
BSDI2
16
Betriebssysteme
Winter2016
SystemV
SeventhEdition
PWB3.0.1
SystemIII
• Commercialversion
– DemergerofAT&T(1985)inhibits
successfulmarketing
SystemV
• Importantimprovement
PWB5.2
– Copy-On-Write
SystemV
Release2
• „SystemVIPC“
– SharedMemory
– UNIXStreams
– Semaphores,etc.
EightEdition
4.2BSD
SystemV
Release3
SunOS3
XENIX
SystemV
Release4
NovellUNIXWare
SunOS/Solaris
Solaris2
4.1cBSD
SunOS
• UNIXbranchofSUNMicrosystems
• ConsolidationofBSD
andSystemVbranches
SunOS3
4.3BSD
• AlsoavailableforPC
SunOS4
SystemV
Release4
Solaris
Solaris2
(c)PeterSturm,UniTrier
17
Betriebssysteme
Winter2016
MACHKERNEL
History
• Famousmicrokernelapproachstarting1984
– RichardRashid,CMU,previouslyworkingontheAccentnetwork
operatingsystemkernel,nowheadofMicrosoftResearch
• Microkerneltocopewiththeeverincreasingcomplexityof
theUNIXoperatingsystem
– Reducethenumberoffeaturesinthekerneltomakeitlesscomplex
• Machkernelimplementsprocessorandmemory
management
– Filesystem,networking,I/Oinauser-levelMachtask
(c)PeterSturm,UniTrier
18
Betriebssysteme
Winter2016
MachAbstractions
• Task
– Containerforalltheresourceofoneormorethreads
• Includesvirtualmemory,ports,processors,…
• Thread
– Basicunitofexecution
• Port
– In-kernelmessagequeuewithcapabilities
• Message
– Collectionofdatasentbetweenthreadsindifferenttasksusingports
• MemoryObject
– Containerofdatamappedintoatask‘saddressspace
MachMonolithsorMicrokernels
• Monolithsduetoperformanceissues(Mach2and2.5)
– BSD,OSF/1,NEXTSTEP,OPENSTEP
• TrueMicrokernelwithversion3
–
–
–
–
–
StartedatCMU,continuedbyOSF
KernelpreemptionandRTscheduling
Low-leveldevicesrepresentedasports
System-Callredirection(handlinginuserspace)
Continuations
• threadsmayblockbyspecifyingafunctiontobecalleduponcompletion
(c)PeterSturm,UniTrier
19
Betriebssysteme
Winter2016
MACOSX
Roots
• Quitecomplexhistory(seeSinghfordetails)
• OSKernel
– NuKernelfirst,replacedbyMachkernellater
• OSPersonality
– VariousapproachesincludingTalOS,Copland,Gershwin,BeOS,
– NEXTSTEPandOPENSTEP(withSunMicrosystems)andObjective-C
• Finalproducts
– MacOS8and9
– Rapsody(1997)
(c)PeterSturm,UniTrier
20
Betriebssysteme
Winter2016
FamilyTree
FreeBSD
NetBSD
Mac3.0
OPENSTEP
4.4BSD
Rapsody
MacOS
BlueBox
1998
MacOSXServer1.0
March1999
MacOSXDP1
Darwin0.1
March1999
May1999
MacOSX10.0
March2001
MacOSX10.5
October2007
Architecture
GUIAqua
ApplicationEnvironments
Classic,BSD,X11,Carbon,Cocoa,WebObjects,QuickTime,Java(AWT,Swing)
GraphicsandMultimedia
QuickDraw2D,Quartz,OpenGL,QuickTime,Audio,JRE
CoreServices
JDK,JVM
BSDAPI(Posixu.a.)
Mach
Hardware
(c)PeterSturm,UniTrier
21
Betriebssysteme
Winter2016
MICROSOFTWINDOWS
Overview
• SinceWindowsNTbackin1989…
–
–
–
–
32bitand64bitoperatingsystems
Preemptiveandreentrantscheduling
Fullvirtualmemorysupport
Supportformultiprocessorsystems
• Initialamikrokernel-basedapproachwithanumberoftimecriticalservices“re-integrated”intothekernel
• OSpersonalitiesareimplementedassubsystemsontopof
Windowskernel
– Windowssubsystemcommontoall(providesWin32API)
– SomeserversystemssupportPOSIXsubsystem
– TherewasaOS/2subsystemonce
(c)PeterSturm,UniTrier
22
Betriebssysteme
Winter2016
OverallArchitecture
Subsystem
System
Support
Processes
Service
Processes
User
Applications
Environment
Subsystems
SubsystemDLLs
SystemCall
Interface
Executive
Kernel
Windowing
andGraphics
DeviceDrivers
HardwareAbstractionLayer(HAL)
WindowsExecutive
SystemCallInterface
System Threads
System Service Dispatcher
I/O
Manager
USER
GDI
File
System
Cache
Object
Manager
Plug
and
Play
Manager
Security
Reference
Monitor
Virtual
Memory
Processes
and
Threads
Config
Manager
(Registry)
Local
Procedure
Call
Graphics
Driver
Kernel
Hardware Abstraction Layer (HAL)
(c)PeterSturm,UniTrier
23
Betriebssysteme
Winter2016
Literature
•
D.Bovet,M.Cesati,UnderstandingtheLinuxKernel,3rdEdition,O‘Reilly,2006
•
EricLevenez,Variouschronologiesonoperatingsystems,
http://www.levenez.com
•
J.Mauro,R.McDougall,SolarisInternals,SunMicrosystemsPress,2001
•
M.K.McKusik,K.Bostic,M.J.Karels,J.S.Quarterman,TheDesignand
ImplementationoftheFreeBSDOperatingSystem,Addison-Wesley,2014
•
G.Moody,rebelcode– LinuxandtheOpenSourceRevolution,ThePenguin
Press,2001
•
M.E.Russinovich,D.A.Solomon,MicrosoftWindowsInternals,4th Edition,
MicrosoftPress,2005
•
AmitSingh,MacOSXInternals– ASystemsApproach,Addison-Wesley,2007
•
A.S.Tanenbaum,A.S.Woodhull,TheMinixBook– OperatingSystems,3rd
Edition,Prentice-Hall,2006
•
L.Torvalds,justforfun,HarperBusiness,2001
(c)PeterSturm,UniTrier
24
System Software
Winter 2016
OperatingSystems
VirtualMachines
Virtualisierung
SystemX‘‘
SystemX‘
SystemX
„Virtualizationisaframeworkor
MaschineY‘‘‘
MaschineY‘‘
methodologyofdividingtheresources
ofacomputerintomultipleexecution
environments,byapplyingoneormore
conceptsortechnologiessuchas
hardwareandsoftwarepartitioning,
time-sharing,partialorcomplete
machinesimulation,emulation,quality
ofservice,andmanyothers.”
MaschineY‘=Y
Virtualisierungssoftware
MaschineY
AmithSingh
(c) Peter Sturm, University of Trier
1
System Software
Winter 2016
Vorteile
• Server-Konsolidierung
• Indirektionsstufe
–
–
–
–
–
• TestenundDebugging
• Isolation
– Sandboxing
– Fault/ErrorContainment
• AusführungvonLegacy
Software
– AlteAnwendungen
– AlteBetriebssysteme
Migration
QualityofService
Lastverteilung
Administration
Automatisierung
• Schulungen
• Auslieferungsmediumfür
Anwendungen
– EinsichteninneueSoftware
Nachteile
• Zeit- undPlatzeffizienz
• SchlechtvirtualisierbareHardware
• BereitsimGast-OSgenutzteVirtualisierung
(c) Peter Sturm, University of Trier
2
System Software
Winter 2016
Technikistrechtverbreitet!
• VirtualisierungeinzelnerRessourcen
– Terminal=Window
• AktivesFensterhatFokus(=KeyboardundMaus)
– CPU=Thread
– AdreßraumSpeicher=VirtualMemory
– …
• VirtualisierungganzerRechner
– 16BitWindowsundDOS-Anwendungen
• AusführungineinervirtuellenMaschine
– VirtuelleMaschinenunterschiedlichsterBauart
Ressourcen-Virtualisierung
• BessereAusnutzung
– KontextwechselbeiblockierendemAufruf
– NebenläufigeAnwendungenprofitierenvonMultiprozessoren
• …aberlaufenauchaufMonoprozessoren
• EliminierenvonEngpässen
– MehrSpeicherdurchPaging
– JedeAnwendungbekommtihreigenesTerminal
• Schutz/Isolation
– Anwendungenuntereinanderisoliert
– Betriebssystemvordefekten/bösartigenAnwendungengeschützt
(c) Peter Sturm, University of Trier
3
System Software
Winter 2016
Beispiel„VirtuellerSpeicher“
Stack
Heap
Data
Code
Page
Table
• Abbildungsverfahren
– Ortjedergenutztenvirtuellen
SeiteimSpeicher
RealerAdreßraum
VirtuellerAdreßraum
MMU
• Mehrwert
– IsolationvonAdreßräumen
– Schutz
– BessereSpeichernutzung
• OverheadwirddurchspeziellenCache
(TranslationLookasideBuffer)minimiert
HistorischeWurzeln
(c) Peter Sturm, University of Trier
4
System Software
Winter 2016
Details
• 1959bis1970,IBMfederführend,aberauchMITu.a.
• GeburtsstundedesMulti-ProgrammingundTime-Sharing
– AtlasProject,Manchester (1961)
– Multics,MIT(1963)
– m44/44X,IBM704Serie,CTSS,CP-40,CP-67,VM/370IBM(ca.1965)
• MehrereidentischeKopienderHardware
• KommendeOS-Generationnochzujungundinstabil
• SchnelleNutzungderbesserwerdendenHardware
• EtablierteundzuverlässigeBetriebssystememittelsvirtuellen
Maschinenreplizieren
Virtualisierungsarten
• Emulation
– VollständigeSimulationandererCPUundHardware
• NativeVirtualisierung(FullVirtualization)
– KeineÄnderungdesGastsystems(=Transparenz)
• Paravirtualisierung
– GastsystemesindsichihrerVirtualisierungbewußt
– TransparenzoberhalbdesGastes
• OS-Level-Virtualisierung
– BetriebssystemvirtualisiertmehrereInstanzenseinerselbst
• Anwendungsvirtualisierung
(c) Peter Sturm, University of Trier
5
System Software
Winter 2016
Emulation
• Interpretation
• Übersetzung
– MSVirtualPCfürPPC
– EmulatorenfürAtari,VC64,
AppleII,…
– Rosetta(MACOSX,PPCauf
Intel)
– WOW64(32BitWindowsauf
Itanium2)
– …
• Performanz
NativeVirtualisierung
• BefehlssatzGast=BefehlssatzHost
• Voraussetzungen
– Privilegierterundnicht-privilegierterModus
– GutvirtualisierbareCPU;-)
• Gast-OSführtprivilegierteInstruktion
aus
– VMMinterpretiertBefehlimKontext
dervirtuellenHardware
• WechselzuvirtuellerHardwarefür
Gast-OSunsichtbar
Anwendung
Nicht-Privilegiert
Gast-OS
Nicht-Privilegiert
Anwendung
Virtuelle
Nicht-Privilegiert
Hardware
VMM
OS
Privilegiert
Hardware
(c) Peter Sturm, University of Trier
6
System Software
Winter 2016
Typ-1undTyp-2
Type-2 VMM
Gast1
Type-1 VMM
(Hypervisor)
Gast2
VMM
Gast1
Gast2
HostOS
VMM
Hardware
Hardware
Beispiele
• VMware,Parallels,...
– FortgeschritteneKonzepte
•
•
•
•
•
DragandDrop
Schnappschüsse
Clones
Multimedia
VirtuelleRechnernetze
• MicrosoftVirtualPCund
VirtualServer
• VirtualBoxvonSun
(c) Peter Sturm, University of Trier
7
System Software
Winter 2016
KritischeInstruktionen
• RealeCPUsmehroderwenigergutvirtualisierbar
• x86eherwenigerJ
• Gründe
– Nicht-privilegierteInstruktionengebenAuskunftüberprivilegierte
Hardware-Informationen(Interrupts,…)
– InstruktionsresultatabhängigvomAusführungsmodus
– InstruktionenverändernverstecktenProzessorzustand
• Insgesamt17kritischeInstruktionen
– AusführunglöstkeineExceptionaus
– FürVMMschwererkennbar(z.B.aufwendigeFilterung)
Paravirtualisierung
• Gast-Systemmußangepaßtwerden
• Vorteile
– FürVirtualisierungungünstigeHardware-Eigenschaftenabschwächen
bzw.aufheben
– KritischeInstruktionenvermeiden
– GeringeEffizienzverluste
• Nachteile
– ZugangzumSourcecodenotwendig
• BedeutendsterVertreter:Xen
• StarkesInteresseseitensVMwareundMicrosoft
(c) Peter Sturm, University of Trier
8
System Software
Winter 2016
Xen
Host
Gast1
Gastn
Dom0
Dom1
Domn
XenHypervisor
Hardware
• OpenSourceProjektderUniversitätCambridge
• VolleVirtualisierungmitHW-Unterstützungmöglich
• SpeziellesHostsysteminDom0
– stelltinderRegelTreiberfürE/Abereit
– FührtdiverseXen-Prozesseaus
• GästegreifenübervirtuelleTreiberundHostaufGerätezu
– SharedMemoryundEvents
User-ModeLinux(UML)
• PortierungdesLinux-KernelsaufvirtuelleArchitekturum
• arch/um bildetFunktionalitätaufSystemCallsab
Þ UMLbestehtaus
mehrerenLinux-Prozessen
Anwendungen
Linux
Anwendungen
arch/um
Linux
arch/i386
Hardwarei386
(c) Peter Sturm, University of Trier
Hardwareum
9
System Software
Winter 2016
OS-LevelVirtualisierung
• DünneVirtualisierungsschichtoberhalbdesBetriebssystems
• JedesServer-OSbietetentsprechendeMöglichkeiten
– VirtualEnvironments,VirtualPrivateServers,Jails,vservers,Zones,
Containers,…
• KommerzielleLösungen
• Bemerkungen
– Leichtgewichtig
– Vergleichsweisekomplex
– Meistfangenvorgeschaltete
Kerneltreiberalle
Aufrufeab
Service1
Service2
Service3
OSX
OSX
OSX
Virtualisierungsschicht
OSX
Hardware
Produkte
Wikipedia
(c) Peter Sturm, University of Trier
10
System Software
Winter 2016
ABI/API-Virtualisierung
• WINE
– WindowsAPIaufUNIX/LinuxundX
• CrossOver
– KommerzielleWine-Version
• SUNWABI
– WindowsApplication
BinaryInterface
– fürx86
– EmulationaufSPARC
• …
ApplicationVirtualisierung
• VielÄhnlichkeitmitEmulation,aber…
– keineNachbildungeinesvorhandenenBefehlssatzes
– sonderneigenständige,problemspezifischeLösung
• MeistdeutlichhöhereAbstraktionenalsCPU-Instruktionen
• WichtigsteVertreter
– JavaVirtualMachine(JVM)
– .NETCommonLanguageRuntime(CLR)
• DIELaufzeitplattformenderGegenwart
(c) Peter Sturm, University of Trier
11
System Software
Winter 2016
Beispiele
Wikipedia
WeitereBeispiele
• Web-Server
– VirtualDirectory
– VirtualHost
• ApplicationServer
– EnterpriseJavaBeans
– WeitereIndirektionsstufe
• WPFundWFaus.NET4.5
– Instruktionssätze
• XAML
• XAMLPresentation
• XOML
(c) Peter Sturm, University of Trier
12
System Software
Winter 2016
Microsoft
• DiverseAnsätzeseitmindestens1995inBenutzung
• VirtualDOSMachine(VDM)
– DOS-AnwendungenunterWindowsausführen
• WOW32,WOW64
– Unterstützungfür16-Bit-Anwendungenauf32-Bit-Windowsund32-BitAnwendungenauf64-Bit-Windows
• ABI/API-EmulationenfürOS/2undPOSIX
• ApplicationVirtualization
– SQLServer,IIS,ExchangeServer,TerminalServer,….
• AktuelleProduktlinie
• Ziel:ParavirtualisierteWindows-Betriebssysteme,Hypervisor
WindowsEnlightenment
• ParavirtualisierbareWindows-Betriebssysteme
• SeitLonghorn(CodebaseVistafürServer)
• VerlagerungderTreiberinGast-OS
– VirtualizationProvider
– VirtualizationClient
– DirekterHW-ZugangfürGäste
• Direct3Dbzw.DirectXfürGästezugänglich!!!
(c) Peter Sturm, University of Trier
13
System Software
Winter 2016
Sicherheit
• VMWareSoftware
– RemoteHeapExploitinvmnat.exe
– AngreiferkanneinevirtuelleMaschineverlassenundHost
kompromittieren
• AngriffeaufJVMund.NETCLRdurchFehlerinder
Speicherverwaltung
– S.Govindavajhala,A.W.Appel,Princeton,2003
BluePillAttack
• JoanaRutkowska,COSEINC
• NutztHardwareunterstützungfürVirtualisierung
– MalwarewirdkleinerHypervisor
– OSkommtineinevirtuelleUmgebungundwirdkontrollierbar
– Geht„Onthefly“
• ExploitaufAMD64SVMüberVista
• SchutzmitzusätzlicherHW-Unterstützungmöglich
– AuthenifizierungaufHW-EbenebeimEinrichtenneuerVMs
(c) Peter Sturm, University of Trier
14
System Software
Winter 2016
BlueandRedPill
TheMatrix
writtenbyAndyWachowski&LarryWachowski
Morpheus: Iimaginethatrightnowyou'refeelingabitlikeAlice.Tumblingdowntherabbithole?
Neo: Youcouldsaythat.
Morpheus: Icanseeitinyoureyes.Youhavethelookofamanwhoacceptswhatheseesbecausehe'sexpectingtowake
up.Ironically,thisisnotfarfromthetruth.Doyoubelieveinfate,Neo?
Neo: No.
Morpheus: Whynot?
Neo: 'CauseIdon'tliketheideathatI'mnotincontrolofmylife.
Morpheus: Iknowexactlywhatyoumean.Letmetellyouwhyyou'rehere.You'reherebecauseyouknowsomething.What
youknow,youcan'texplain.Butyoufeelit.Youfeltityourentirelife.Thatthere'ssomethingwrongwiththeworld.You
don'tknowwhatitis,butit'sthere.Likeasplinterinyourmind-- drivingyoumad.Itisthisfeelingthathasbroughtyouto
me.DoyouknowwhatI'mtalkingabout?
Neo: TheMatrix?
Morpheus: Doyouwanttoknowwhatitis?
(Neonodshishead.)
Morpheus: TheMatrixiseverywhere,itisallaroundus.Evennow,inthisveryroom.Youcanseeitwhenyoulookoutyour
window,orwhenyouturnonyourtelevision.Youcanfeelitwhenyougotowork,orwhengotochurchorwhenyoupay
yourtaxes.Itistheworldthathasbeenpulledoveryoureyestoblindyoufromthetruth.
Neo: Whattruth?
Morpheus: Thatyouareaslave,Neo.Likeeveryoneelse,youwerebornintobondage,borninsideaprisonthatyoucannot
smell,taste,ortouch.Aprisonforyourmind.(longpause,sighs) Unfortunately,noonecanbetoldwhattheMatrixis.You
havetoseeitforyourself.Thisisyourlastchance.Afterthis,thereisnoturningback.
(Inhislefthand,Morpheusshowsabluepill.)
Morpheus: Youtakethebluepillandthestoryends.Youwakeinyourbedandbelievewhateveryouwanttobelieve.(ared
pillisshowninhisotherhand) YoutaketheredpillandyoustayinWonderlandandIshowyouhowdeeptherabbit-hole
goes.(Longpause;Neobeginstoreachfortheredpill) Remember-- allIamofferingisthetruth,nothingmore.
(Neotakestheredpillandswallowsitwithaglassofwater)
TRENDS
(c) Peter Sturm, University of Trier
15
System Software
Winter 2016
Trends
• MehrFunktionalität
– MigrationvirtuellerMaschinenimlaufendenBetrieb
– Konvertierung
• AusrealerInstallationwirdvirtuelleInstallation
• AusvirtuellerInstallationwirdrealeInstallation
• ZwischenverschiedenenvirtuellenFormaten
• MehrStandards
– OffenlegungderFormatevirtuellerFestplatten
– ManagementkomplexervirtuellerInfrastrukturen
• MehrHardwareunterstützung
– ParavirtualisierungbeiHardwaretreibern
• Zugriffauf3D-FeaturesmodernerGraphikkartenindervirtuellenMaschine
– DirekterSupportinmodernenCPUs
Visionen?!
• VirtuelleMaschinenwerdenimmer„billiger“
– AusreichendvieleCPUsvorhanden
– KompakteImages
• SnapshotswerdenalsDeltasgespeichert
• MehrereVMsnutzengleicheCodebasis
• Hypervisor+VirtuelleMaschinenwirdNormalfall
• „WennderProphetnichtzumBergkommt,…“
– BetriebssystemeerlaubensaubereAnwendungsstrukturen
– AbervieleAnwendungenwerden„unsauber“realisiert
– JedeAnwendungbekommteigenevirtuelleHardware
• VirtuelleMaschinenwerdenEinheitendesDeployments
(c) Peter Sturm, University of Trier
16
System Software
Winter 2016
VirtuelleZeiten
• Anwendungenwerdenalsvorkonfiguriertevirtuelle
Maschinenausgeliefert
–
–
–
–
BessereIsolation
WenigerWechselwirkungen
ErhöhteFlexibilität
ErhöhteMobilität
• VieleVMslaufenaufjeweilseinemRechner
– Zeit- undPlatzeffizienz
• RenaissanceinForschungundEntwicklung
• VirtualisierungstechnikensindneueralterTrend
Trend
OnBoard Hypervisor
(c) Peter Sturm, University of Trier
17
System Software
Winter 2016
Trend:Hypervisorwandeltsich
• 1.Generation
– Hosted Typ-2-Hypervisor
Hardware
HostBetriebssystem
Hypervisor
GastBetriebssystem
Applikation
MehrTyp1?
• NativeTyp-1-Hypervisor
Hardware
Hypervisor
Gast
Betriebssystem
Applikation
(c) Peter Sturm, University of Trier
18
System Software
Winter 2016
Trend…
• Managed Code
Hardware
Hypervisor
Gast
Betriebssystem
Managed Runtime
Environment
Applikation
Trend:Gast-OSwandeltsich
• BeispielESXServer3i
– TeilmengederPOSIXOS-API
– VSockets überVMCI(zukünftig)
– Microkernel++?
• Canonical JeOS
– JustEnough OperatingSystem
– Minimal-Ubuntu fürVirtualAppliances
– FürESXServer3iHypervisor
HW
HV
RTE
• BEALiquidVM
– JVMfürdenHypervisor
– FürVirtualAppliances
Applikation
• MicrosoftServerCore
– Konfigurierbarer minimalWindowsServerohneGUI
(c) Peter Sturm, University of Trier
19
System Software
Winter 2016
Odernochschlimmer...
• ...BrowseristdasBetriebssystem
– VergleichbarJVModerCLR
• BeispielChrome
HW
• Trend„RichInternetApplications“(RIAs)
– AspektverteilterSysteme
– IntegrationvonCloudsbzw.*aaS
Minimal
OS
Browser
RIA
Hardwareunterstützung
• SupportfürvirtuelleMaschinen
– Unzulänglichkeitenderx86-Architekturbzgl.Virtualisierungbeseitigen
– IntelVT(früherVanderpool)
– AMDV(früherPacifica)
• IOMMU
–
–
–
–
VirtuelleAdreßabbildungundSchutzbeiDMA-Zugriffen
Legacy32-Bit-Supportauf64-Bit-Systemen
DirekterabergeschützterZugriffvirtuellerGästeaufHardware
DirekterabergeschützterZugriffvonAnwendungenaugfHardware
(c) Peter Sturm, University of Trier
20
System Software
Winter 2016
IntelVT
VM Entry
Host-State
Area
Guest-State
Area
VM Exit
• ZweiRealisierungen
– x86-Architektur:VT-x
– Itanium:VT-i
• VMExitssindkonfiguierbar
–
–
–
–
WelcheExceptionsollExitauslösen?
WelcherI/O-Zugriff?
WelchemaschinenspezifischenRegistersindgeschützt?
WelchekritischenInstruktionen?
Trend:VMalsEinheitdesDeployment
• OpenVirtualMachine Format(OVF)
– PortabelundHV-unabhängig
– XML-basierterStandardzumAustauschvirtuellerMaschinen
– Unterstützt„VirtualAppliances“/„SoftwareAppliances“
• „NichtnurBetriebssystemesondernApplikationen“
• VirtualAppliances
– VM-EnsemblesalseinheitlicheApplikation
– BeispielCRM-Applikation
• WebServer,Datenbank-Server,Frontend,…
• JedeKomponenteeineVM
– Einfache„Installation“
(c) Peter Sturm, University of Trier
21
System Software
Winter 2016
Standards
• ImageSpezifikationen
– InterneRepräsentationdervirtuellenLaufwerkeoffengelegt
• VMware
• Microsoft
• Zusammenarbeitbei
– DefinitioneinesParavirtualisierungs-APIs
• WindowsaufXenohneSourcecodeundHWmöglich
– EinheitlicheManagement-APIs
• UmstiegvonAppleaufIntel-CPUshatSzenebelebt
(c) Peter Sturm, University of Trier
22
System Software
Winter 2016
Record/Replay
• KompletteKontrollederZeitausSichteinerVM
– VollkommendeterministischeAusführung
• Einsatzszenarien
– Software-Tests/Debugging
•
•
•
•
ExakteReproduzierbarkeitvonFehlern
Race-Conditions
AlsLoganEntwicklerliefern
Debuggernachträglicheinhängen
– Consumer
• Recovery imtäglichenEinsatz?
• VM-basierteWiederherstellungspunkte?
(c) Peter Sturm, University of Trier
23
Betriebssysteme
Winter2016
CONTAINER
DOCKER ET AL.
Steffen Gebert (Uni Würzburg) & Peter Sturm
©Gebert/Sturm
1
Betriebssysteme
Winter2016
VIRTUELLE MASCHINEN
• Pflegen wir, als wären es reale
• Installieren Updates
• Schauen wir uns bei Fehlern genauer an
• Geben wir bedeutungsvolle Hostnamen
• Hängen an deren Existenz
JAILS
©Gebert/Sturm
2
Betriebssysteme
Winter2016
OS LAYER VIRTUALISIERUNG
• OS virtualisiert hinter dem System Call API
• chroot, Jails, u.a.
System Calls
Betriebssystem
OS LAYER VIRTUALISIERUNG
• OS virtualisiert hinter dem System Call API
• chroot, Jails, u.a.
System Calls
Virtualisierung
Betriebssystem
©Gebert/Sturm
3
Betriebssysteme
Winter2016
NEUE KLEIDER?
• Wieder neue Kleider
• Diesmal aber mit mehr Power
• Klappt vielleicht besser als beim letzten Mal
VIRTUELLE MASCHINE à CONTAINER
• Container sind zum Wegwerfen
• Sind sehr schnell instanziiert
VM
• Gleicher Kernel wie Hostsystem
• Virtualisierung von
Container
• Prozessbaum
• Netzwerkstack
• Filesystem
©Gebert/Sturm
4
Betriebssysteme
Winter2016
ANWENDUNGS-DEPLOYMENT
Kernel
Systemd
SSH
Docker
Python
Java
Nginx
MySQL
OpenSSL
OS
App
Deployment
Python
Java
Nginx
MySQL
OpenSSL
Kernel
Systemd
SSH
Docker
OS
App
Deployment
• Traditionell:
• Python/Ruby/Java/Tomcat etc. Teil des OS
• Container:
• Plattform + Anwendung = Container = deploybares Artefakts
CONTAINER == DOCKER ?!
• Docker-Projekt hat Container populär gemacht
• Linux Container (LXC) als leichtgewichtige Virtualisierungstechnik
• Vereinfacht Handling von Containern (LXC schwer handhabbar)
©Gebert/Sturm
5
Betriebssysteme
Winter2016
DOCKER: STORE
DOCKER: HUB
• Zentrale Registry (Artefaktrepository) für Images
(http://hub.docker.com oder Unternehmens-Registry)
• Jeder kann Container auf Basis vorhandener Images starten
• Docker Host lädt fehlende Images automatisch
• Self-service-Angebot für Entwickler/Mitarbeiter
©Gebert/Sturm
6
Betriebssysteme
Winter2016
DOCKER: UNION FILESYSTEM
• Zu kopierende Daten bei Starten eines Docker-Containers: 0
• Zeitdauer zum Starten: Nahezu 0
• Overlay/Union-Filesystem
• Schreibzugriffe werden in neuen Layer gelenkt
writeable
Applic. XYZ
Tomcat
Base
Ubuntu
WO LÄUFT DOCKER?
• Docker Container laufen auf allen modernen Linux-Distros
• Für Produktivbetrieb: Auf Docker spezialisierte Distros
• Weniger installierte Software
• Integrierte Management-Tools
• Public Clouds: In virtueller Maschine
©Gebert/Sturm
7
Betriebssysteme
Winter2016
COREOS
• Kein Paketmanager, nur Docker und wenige Userland-Tools
• Hostsysteme werden zentral aktualisiert
• Aktualisierungsquote festlegbar
• Fallback-System auf 2. Partition installieren
• Automatischer Reboot
MICROSOFT VS. DOCKER?
• Microsoft findet Docker toll
• Docker-Support in Azure schon länger
• Partnerschaft mit Docker Inc. seit Okt 2014
• Diverse Beiträge zum Docker Code
©Gebert/Sturm
8
Betriebssysteme
Winter2016
WINDOWS CONTAINER
• Neu in Windows Server 10
• Docker-kompatibel
• Zwei Varianten
• Windows Server Container (direkt auf Hardware)
• Hyper-V Container (in Hyper-V und z.B. Azure, Multi-Tenancy)
“new level of isolation” [wie wir es nur von VMs gewohnt sind]
MICROSOFT NANO SERVER
• Abgespeckter Server Core
• Kein MSI Installer, kein WOW64 (= 32 Bit Support)
• Keinerlei Nutzer-Interfaces (auch nicht lokales CLI)
• Konfiguration über PowerShell bzw. Desired State Configuration (DSC)
©Gebert/Sturm
9
Betriebssysteme
Winter2016
CONTAINER MANAGEMENT
COREOS: FLEET
• Verteilt Container auf laufende Hosts
• Hält immer festgelegte Anzahl Instanzen am Laufen
• Startet bei Bedarf zusätzliche
• Tagging (z.B. app, db) erlaubt Container auf bestimmten
Host-Typen zu starten
©Gebert/Sturm
10
Betriebssysteme
Winter2016
KUBERNETES
• Management und Orchestrierung
von Containern
• Pods fassen mehrere Container
zusammen
• Policies legen Eigenschaften der
Dienste fest
• Basisimages, Versionen, Ports, Volumes
MESOS
• 2009 an der UC Berkeley erschaffen, Apache Top-Level Project
• Abstraktion der Data Center Ressourcen
• Datacenter operating system („program against your datacenter like
it‘s a single pool of resources“)
• APIs für zahlreiche Sprachen
• Fehlererkennung und –korrektur / High Availability
• 2-Layer Scheduling
• Resourcenverwaltung gegenüber Frameworks, diese wiederum ggü.
Applikation
• Docker-basierte Scheduler neben anderen Frameworks
• Nutzer: Twitter, Airbnb, Apple‘s Siri
©Gebert/Sturm
11
Betriebssysteme
Winter2016
MESOS ALS DATA CENTER KERNEL
DOCKER SWARM
• Integraler Bestandteil von Docker
• Zugang über Standard Docker API
• Unterstützung vorhandener Tools
• { Docker Hosts } = Virtueller Docker Host
• Node API
• Kritik: Node API != Cluster API
• Kubernetes u.a. mehr als Swarm
©Gebert/Sturm
12
Betriebssysteme
©Gebert/Sturm
Winter2016
13
Betriebssysteme
Winter2016
Innovative
Architekturansätze
PeterSturm
AGSystemsoftware
BetriebssystemeimUmbruch
• AllgemeineProbleme
– SteigendeKomplexität
– MangelndeZuverlässigkeit
• NeueHerausforderungen
– ManyCore-Architekturen
• NeueAnwendungsszenarien
– RIAs
– ManagedApplications
(c)PeterSturm,UniversityofTrier
1
Betriebssysteme
Winter2016
ChromeOS+ChromiumOS
• Kategorie„Justenoughoperatingsystem“
• ChromoOS=Google„Produkt“
• ChromiumOS=OpenSourceProjekt
Applications(JavaScript,RIA,...)
ChromeBrowser
Customization
LinuxDerivat
MicrosoftSingularity
• ForschungsprojektvonMicrosoftResearch
– 2004– ~2009
• DesignPrinzipien
–
–
–
–
–
KompletterNeubeginn(NameJ )
KeineAbwärtskompatibilität
FokusaufZuverlässigkeit
TypsichereSprachenundSoftwareverifikation
Microkernel-Architektur
wikipedia
(c)PeterSturm,UniversityofTrier
2
Betriebssysteme
Winter2016
Adressräume
• Isolationvon…
– VerschiedenenProzessen
– KernelundProzessen
• Grund?
– UnmanagedCode
• C/C++,Assembler,…
– NichttypsichereSprachen
– PotenziellfehlerhafteVerwendungvonPointern
SingularityAnsatz
App
App
Dateisystem
Treiber
CLR
CLR
CLR
CLR
CLR
GC
GC
GC
GC
GC
…
…
TCP/IP
Stack
ABI
CLR
Garbage
Collector
Kernel(C#)
Adressraum
KernelMode
è KeineWechselvonAdressräumenmehrnotwendig!
(c)PeterSturm,UniversityofTrier
3
Betriebssysteme
Winter2016
Software-isolierteProzesse(SIPs)
• AllesimgleichenAdressraum!
– Kernel,Treiber,Applikationen
• Isolation
–
–
–
–
TypsichereSprache(keinePointer)
AlleReferenzenexplizitundtypisiert
VerifikationwährendderÜbersetzung
Isolationistformalbeweisbar!
• KeineIsolationaufHW-Ebene
– Nichtnotwendig
– KeinAdressraumwechsel
– KeinekaltenCaches/TLBs,…
è Microkernel-Ansatzwirdeffizient!
Software-isolierteProzesse(SIPs)
• VerifikationzurÜbersetzungszeit
– Deshalb(momentan)…
• KeineCode-GenerierungzurLaufzeit
• KeindynamischnachgeladenerCode
(c)PeterSturm,UniversityofTrier
4
Betriebssysteme
Winter2016
InterprozessKommunikation
• KompletteIsolation?
• InteraktionnurüberspezielleKommunikationskanäle
– Nachrichtentypen+AbfolgeperKontraktspezifiziert
– CompilerüberprüftkorrekteVerwendung
• Abhängigkeiten
– VollständigüberKontraktespezifiziert
– ZwischenallenSIPs
• Treiber,Applikationen,Kernel,Dateisystem,…
Sing#
• C#-DialektSing#
• KommunikationundKontrakteaufSprachebene
–
–
–
–
DefinitionvonEndpunkten
Empfangvon(mehreren)Nachrichten
SendenvonNachrichten
Zustandsmodell
(c)PeterSturm,UniversityofTrier
5
Betriebssysteme
Winter2016
public contract TcpConnectionContract {
in message Connect(uint dstIP, ushort dstPort);
out message Ready();
state Start : Ready! -> ReadyState;
state ReadyState : one {
Connect? -> ConnectResult;
BindLocalEndPoint? -> BindResult;
Close? -> Closed;
}
state BindResult : one {
OK! -> Bound;
InvalidEndPoint! -> ReadyState;
}
in message Listen();
state Bound : one {
Listen? -> ListenResult;
Connect? -> ConnectResult;
Close? -> Closed;
}
…
}
TechnischeUmsetzung
• EffizienteNachrichtenkommunikation?
App
App
Dateisystem
Treiber
CLR
CLR
CLR
CLR
CLR
GC
GC
GC
GC
GC
…
…
TCP/IP
Stack
ABI
CLR
(c)PeterSturm,UniversityofTrier
Garbage
Collector
Kernel(C#)
Exchange
Heap
6
Betriebssysteme
Winter2016
ExchangeHeap
• DurchKernelverwalteteDatenstruktur
– EnthälttypisierteNachrichten
– KernelerlaubtundentziehtZugriffaufTeiledesHeaps
• AustauscheinerNachricht
– ReferenzaufNachrichtanKernelübergeben
– KernelbenachrichtigtEmpfängerundgibtihmReferenzaufdie
Nachricht
è Simple„Pointer“-Operation
• Invariante
– ZujedemZeitpunkthatnureinProzeßeineReferenzaufTeildes
ExchangeHeaps
– VerifikationdurchCompileraufBasisdesKontrakts
Composability
• AktuelleBetriebssysteme?
– WelcheAuswirkunghatdieInstallationderSoftwareXaufdierestliche
Software?
– Kaumvorhersehbar
• Ziel
– ExpliziteAbhängigkeiten
– VorhersagbarkeitvonEffektenundFehlern
• z.B.beiFehlerineinerKomponenteabhängigeKomponenten
benachrichtigen/neustarten
(c)PeterSturm,UniversityofTrier
7
Betriebssysteme
Winter2016
Performance?
LandläufigeMeinung
InC/C++geschriebeneSoftwareläuftschneller
alsSoftware,dieinC#oderJAVAgeschrieben
wurden!
AufdenzweitenBlick…
• Performancevorteile
– IPCohneKontextwechsel
– KernelaufrufeohneKontextwechsel
– KeineRuntimeChecksnotwendig
à CheckseinmaligbeiderÜbersetzung
if(ptr!=NULL)
*ptr…
• Benchmark-Ergebnisse
– Faktor5– 10schnelleralsaktuelleBetriebssysteme
(FreeBSD,Linux,Windows)
(c)PeterSturm,UniversityofTrier
8
Betriebssysteme
Winter2016
MICROSOFTMIDORI
MicrosoftMidori
• ForschungsprototypmitPraxisbezug
– Sogenanntes„Incubation“-Projekt
– BasiertaufSingularity
– Geheimnisumwittert
• Spekulationen
– ZukünftigeWindows-Version?
– Bislangwenigtechnische
Detailsbekannt
• TrendzuformalenMethoden
(c)PeterSturm,UniversityofTrier
9
Betriebssysteme
Winter2016
MidoriProgrammiermodell
• „Concurrency“
–
–
–
–
AsynchroneOSAPI
KommunikationüberasynchroneNachrichten
ErlaubtbessereMultiCoreSkalierbarkeit
siehez.B.auchMSRoboticsStudio
• „DistributedConcurrency“
– EinbeziehungentfernterKomponenten
– à CloudComputing
– ProgrammiermodellunterstütztNachrichtenverlust,Latenzen,
sporadischeKonnektivität
Virtualisierungsaspekte
• VirtualisierbarkeitdesKernels
– Nativausführbaraufx86,x86undARM
– AusführungimHypervisor
• typsichereInteraktionzwischenHypervisorundKernel
– AusführungineinemWindows-Prozess
(c)PeterSturm,UniversityofTrier
10
Betriebssysteme
Winter2016
Quellen
•
Artikel
•
SingularityalsSourceCodeundbootbaresImage
•
Channel9Videos
– GalenC.Hunt,JamesR.Larus,Singularity:RethinkingtheSoftwareStack,ACMSIGOPSOperating
SystemsReview,vol.41,no.2,pp.37-49,Apr.2007
– MarkAikenetal.,DeconstructingProcessIsolation,inACMSIGPLANWorkshoponMemory
SystemsPerformanceandCorrectness,pp.1-10,ACM,SanJose,CA,Oct.2006
– GalenHuntetal.,AnOverviewoftheSingularityProject,no.MSR-TR-2005-135,pp.44,Microsoft
Research,Oct.200
http://www.codeplex.com/singularity
http://channel9.msdn.com
•
ErsteMidori-Fakten
http://www.sdtimes.com/MICROSOFT_S_PLANS_FOR_POST_WINDOWS_OS_REVEALED
(c)PeterSturm,UniversityofTrier
11
Betriebssysteme
Winter2016
CONCURRENCY
Auf der Suche nach dem heiligen Gral der ManyCores
Peter Sturm
PROGRAMMING MODEL
• „Unlimited” virtual memory
• „Unlimited” number of virtual
CPUs
• Mechanisms to synchronize
concurrent threads
• Way to communicate
• Between applications on
a single host (IPC)
• Between hosts in a network
• Persistent storage of information
(file system)
(c)PeterSturm,UniversitätTrier
1
Betriebssysteme
Winter2016
VISION
• Assume that there is an unlimited number of processors
available
• Within an application
• The required number of processors primarily depends on the
inherent parallelism
• Between application
• Every application may have its own processors
Adress Space
Stack
Stack
Stack
CPU
CPU
CPU
Stack
CPU
Stack
Stack
CPU
Address
Space 1
CPU
Stack
CPU
WHY “UNLIMITED” CPUS?
Address
Space n
• Abstract from the number of CPUs on a given computer
• Exploit concurrency inherent to an application
• Utilize possible parallelism of multiprocessor systems
• Other reasons for multiple threads
• Improve response time of interactive applications
• Utilize parallelism available in most modern computer hardware
(c)PeterSturm,UniversitätTrier
2
Betriebssysteme
Winter2016
Stack
CPU
Stack
CPU
Stack
CPU
CPU
CPU
CPU
CPU MULTIPLEXING
Virtual
Address Space
… BUT 1 PHYSICAL CPU AVAILABLE?
• Easy to map many virtual CPUs to a physical CPU
• A "Thread of Control" consists of
• Address space
• State of registers
• Stack (already part of address space)
• Context Switch
• Save current thread state
• Restore another thread state
• When to switch
• Calls that might block for a longer period of time
• Implicitly, e.g. in case of page fault or memory congestion
(c)PeterSturm,UniversitätTrier
3
Betriebssysteme
Winter2016
MODEL OF THREAD STATES
Threads are ready to
run and await CPU
assigment
Threads are
executed by
some CPU
Ready
Running
Blocked
Threads wait for some
condition and can’t
execute
STATE TRANSISTIONS
Resign
Which thread should
be assigned
= Scheduling
Add
Ready
Assign
Ready
Running
Terminate
Block
Blocked
(c)PeterSturm,UniversitätTrier
4
Betriebssysteme
Winter2016
COMPETITION AND COOPERATION
• Competition
• Cooperation
• Applications compete for
resources
• Sharing of resources and tasks
• Goal: Sole user of system
• Implicit Synchronization
• Virtual resources
• Serialization by OS
• Mutual exclusion
(c)PeterSturm,UniversitätTrier
• Applications (Threads) cooperate
• Goals
• Performance improvement
• Avoidance of bottlenecks
• Fault tolerance
• Mutual exclusion and more
specific synchronization patterns
5
Betriebssysteme
Winter2016
AUTOVERKEHR
• 61.5 Millionen zugelassene Autos (Anfang 2014)
Quelle: Statistisches Bundesamt
(c)PeterSturm,UniversitätTrier
6
Betriebssysteme
Winter2016
SPERRGRANULAT
Die Zeit
(c)PeterSturm,UniversitätTrier
7
Betriebssysteme
(c)PeterSturm,UniversitätTrier
Winter2016
8
Betriebssysteme
(c)PeterSturm,UniversitätTrier
Winter2016
9
Betriebssysteme
Winter2016
LOCK-FREE
(c)PeterSturm,UniversitätTrier
10
Betriebssysteme
Winter2016
ANWENDUNGSPROGRAMMIERUNG
• Parallele CPUs
• Diverse parallele Pipelines
• SIMD-Extensions (Single Instruction Multiple Data)
• ManyCores
• CPUs
• GPUs (über 1000 Kerne)
• Cluster
• Verteilte Systeme
GUTE ALTE ZEIT
Threads, Mutex und Semaphore
(c)PeterSturm,UniversitätTrier
11
Betriebssysteme
Winter2016
THREADS
(c)PeterSturm,UniversitätTrier
12
Betriebssysteme
Winter2016
SEMAPHORE
P
Semaphore
• Fundamental synchronization primitive
• Two basic functions (on a semaphore s)
• s.P()
• May block in case semaphore already “occupied”
• s.V()
• Never blocks; releases semaphore and may free a blocked thread
• Dijkstra (1968), “THE” Multiprogramming System
• P = passeren (request entry)
• V = vrygeven (release)
(c)PeterSturm,UniversitätTrier
13
Betriebssysteme
Winter2016
SEMANTIC
• Semaphores are counting signals
Of course, P and V
themselves are critical
sections and must be
protected!
• s.P(): Thread waits for some signal s
void P () {
s.value--;
if (s.value < 0)
Semaphor = Integer
(s.value)
Block calling thread;
}
• Initialized with a s.value ≥ 0
• s.V(): Thread sends a signal s
•
void V () {
s.value++;
if (s.value < 1)
Put a thread waiting in s into ready queue;
}
IMPLEMENTATION
S:
value
queue
TCB
P
TCB
TCB
V
• s.value--;
Execution of P must be atomic
if (s.value < 0) {
• Thread k calls P
tail(s.queue) :=
k;
block(k);
}
(c)PeterSturm,UniversitätTrier
• Execution of V must be atomic
• s.value++;
Calling thread normally doesn’t
if
(s.value <= 0) {
block
ready(head(s.queue))
delhead(s.queue)
}
14
Betriebssysteme
Winter2016
SEMAPHOR
(c)PeterSturm,UniversitätTrier
15
Betriebssysteme
Winter2016
INTERLOCKED
PRODUCER
CONSUMER
(c)PeterSturm,UniversitätTrier
16
Betriebssysteme
Winter2016
MOTIVATION
Producers
Buffer
• Erzeuger und Verbraucher
Consumers
• Puffer fester Größe
• Geschwindigkeitsunterschiede
• Wie löst man das Problem?
OUTLINE OF BUFFER
public class Buffer
{
public Buffer ( int n )
{
}
/// Inserts another good into the buffer.
/// May block until free space is available.
public void Produce ( int good )
{
}
}
(c)PeterSturm,UniversitätTrier
/// Consumes a good stored inside the buffer.
/// May signal blocked producer threads.
public int Consume ()
{
return 42;
}
17
Betriebssysteme
Winter2016
PRODUCER (C#)
public class Producer
{
public Producer ( Buffer b )
{
buffer = b;
my_id = this.GetHashCode();
ThreadStart ts = new ThreadStart(Run);
my_thread = new Thread(ts);
my_thread.Start();
}
private void Run ()
{
Console.WriteLine("Producer {0}: started ...",my_id);
int good = this.GetHashCode() * 1000000;
while (true)
{
buffer.Produce(good);
Console.WriteLine("Producer {0}: good {1} stored",my_id,good);
good++;
}
}
}
private Buffer buffer;
private Thread my_thread;
private int my_id;
CONSUMER (C#)
public class Consumer
{
public Consumer ( Buffer b )
{
buffer = b;
my_id = this.GetHashCode();
ThreadStart ts = new ThreadStart(Run);
my_thread = new Thread(ts);
my_thread.Start();
}
private void Run ()
{
Console.WriteLine("Consumer {0}: started ...",my_id);
while (true)
{
int good = buffer.Consume();
Console.WriteLine("Consumer {0}: good {1} retrieved",my_id,good);
}
}
}
(c)PeterSturm,UniversitätTrier
private Buffer buffer;
private Thread my_thread;
private int my_id;
18
Betriebssysteme
Winter2016
public class Buffer
{
public Buffer ( int n )
{
this.n = n;
slots = new int[n];
mutex = new Semaphore(1);
slots_available = new Semaphore(n);
goods_available = new Semaphore(0);
}
…
}
private
private
private
private
private
private
private
int n;
int [] slots;
int free = 0;
int used = 0;
Semaphore mutex;
Semaphore slots_available;
Semaphore goods_available;
THE BUFFER (C#)
public void Produce ( int good )
{
slots_available.P();
mutex.P();
slots[free] = good;
free = (free+1) % n;
mutex.V();
goods_available.V();
}
public int Consume ()
{
goods_available.P();
mutex.P();
int good = slots[used];
used = (used+1) % n;
mutex.V();
slots_available.V();
return good;
}
THE OPTIMAL BUFFER (C#)
public class Buffer
{
public Buffer ( int n )
{
this.n = n;
slots = new int[n];
mutex_p = new Semaphore(1);
mutex_c = new Semaphore(1);
slots_available = new Semaphore(n);
goods_available = new Semaphore(0);
}
…
}
private
private
private
private
private
private
private
int n;
int [] slots;
int free = 0;
int used = 0;
Semaphore mutex_p, mutex_c;
Semaphore slots_available;
Semaphore goods_available;
(c)PeterSturm,UniversitätTrier
public void Produce ( int good )
{
slots_available.P();
mutex_p.P();
slots[free] = good;
free = (free+1) % n;
mutex_p.V();
goods_available.V();
}
public int Consume ()
{
goods_available.P();
mutex_c.P();
int good = slots[used];
used = (used+1) % n;
mutex_c.V();
slots_available.V();
return good;
}
19
Betriebssysteme
Winter2016
READER/WRITER
THE PROBLEM
Shared Data
• A shared data structure is used by multiple threads
• Writer threads
• These threads modify the shared data and require mutual exclusion
• Reader threads
• Since readers don’t modify data, they can access the shared data
structure simultaneously
(c)PeterSturm,UniversitätTrier
20
Betriebssysteme
Winter2016
STARTING POINT: MUTUAL EXCLUSION
Semaphore Sanctum = new Semaphore(1);
Shared Data
while (true) {
Sanctum.P();
// Change data
Sanctum.V();
}
while (true) {
Sanctum.P();
// Read data
Sanctum.V();
}
Writer
Reader
READER PREFERENCE (FAULTY)
Shared Data
Semaphore Sanctum = new Semaphore(1);
int readers_inside = 0;
while (true) {
Sanctum.P();
// Change data
Sanctum.V();
}
Writer
(c)PeterSturm,UniversitätTrier
while (true) {
if (readers_inside == 0)
Sanctum.P();
readers_inside++;
// Read data
readers_inside--;
if (readers_inside == 0)
Sanctum.V();
}
Reader
21
Betriebssysteme
Winter2016
WHY DOES IT FAIL?
while (true) {
if (readers_inside == 0)
Sanctum.P();
readers_inside++;
// Read data
readers_inside--;
if (readers_inside == 0)
Sanctum.V();
}
Reader
• Multiple readers may
access the shared
variable readers_inside
concurrently
• Testing and setting
variable must be atomic
among readers
• Mutual exclusion
required
2. READER PREFERENCE (CORRECT)
Shared Data
Semaphore Sanctum = new Semaphore(1);
Semaphore RMutex = new Semaphore(1);
int readers_inside = 0;
while (true) {
Sanctum.P();
// Change data
Sanctum.V();
}
Writer
(c)PeterSturm,UniversitätTrier
while (true) {
RMutex.P();
if (readers_inside == 0)
Sanctum.P();
readers_inside++;
RMutex.V();
// Read data
RMutex.P();
readers_inside--;
if (readers_inside == 0)
Sanctum.V();
RMutex.V();
}
Reader
22
Betriebssysteme
Winter2016
READER/WRITER (PRIO WRITER)
Shared Data
Semaphore Sanctum = new Semaphore(1);
Semaphore RMutex = new Semaphore(1);
Semaphore WMutex = new Semaphore(1);
Semaphore PreferWriter = new Semaphore(1);
Semaphore ReaderQueue = new Semaphore(1);
int readers_inside = 0;
int writers_interested = 0;
while (true) {
WMutex.Enter();
if (writers_interested == 0)
PreferWriter.Enter();
writers_interested++;
WMutex.Leave();
Sanctum.Enter();
// Change data
Sanctum.Leave();
WMutex.Enter();
writers_interested--;
if (writers_interested == 0)
PreferWriter.Leave();
WMutex.Leave();
}
Writer
(c)PeterSturm,UniversitätTrier
while (true) {
ReaderQueue.Enter();
PreferWriter.Enter();
RMutex.Enter();
if (readers_inside == 0)
Sanctum.Enter();
readers_inside++;
RMutex.Leave();
PreferWriter.Leave();
ReaderQueue.Leave();
// Read data
RMutex.Enter();
readers_inside--;
if (readers_inside == 0)
Sanctum.Leave();
RMutex.Leave();
}
Reader
23
Betriebssysteme
Winter2016
SPIN LOCKS
ATOMIC READ AND WRITE CYCLE
Address bus
\Valid Address
Read Address
Write Address
\Read
\Write
Data bus
Atomic
• Combined read and write cycle to a single address
• Not interruptable even on a multiprocessor system
• All modern CPUs offer such instructions
• SPARC: LDSTUB (Atomic Load-Store Unsigned Byte), SWAP
• 680x0: TAS (Test and Set)
• No privileged instructions required for synchronization
(c)PeterSturm,UniversitätTrier
24
Betriebssysteme
Winter2016
EXAMPLE USING ATOMIC “TEST AND SET”
• h = TAS Address
• h := Memory[Address]
• Memory[Address] := 1
Spinlock
…
Loop: h = TAS mutex
if (h) goto Loop
// mutex is now 1
…
Loop: h = TAS mutex
if (h) goto Loop
// mutex is now 1
// Critical section
// Critical section
mutex = 0;
mutex = 0;
Thread 1
Thread n
WHERE TO USE?
• Useful only for short waiting time
• Accessing the scheduling queues on a ManyCore CPU
• Synchronizing on a hardware event happening in the near future
• Potential risks
• Starvation, Livelocks, …
• Performance with respect to multiprocessors and caching
(c)PeterSturm,UniversitätTrier
25
Betriebssysteme
Winter2016
SPINLOCKS
Running
Ready
Blocked
SPINLOCKS
Running
Ready
Blocked
(c)PeterSturm,UniversitätTrier
26
Betriebssysteme
Winter2016
?
IMMER WICHTIGER!
• Schnelle Kommunikation bei kooperierenden Threads
• Gleichzeitige Ausführung
• Gang Scheduling
(c)PeterSturm,UniversitätTrier
27
Betriebssysteme
Winter2016
.NET SUPPORT
• Class Interlocked in System.Threading
• static int Increment (ref int x)
• Increments variable x atomically and returns result
• static int Decrement (ref int x)
• Decrements variable x atomically and returns result
• static int Exchange (ref int x, int y)
• Assigns value y to variable x atomically and retuns the previous value
• static int CompareExchange (ref int x, int y, int c)
• Assigns value y to x atomically iff x == c; returns previous value of x
(c)PeterSturm,UniversitätTrier
28
Betriebssysteme
Winter2016
SPINLOCK EXAMPLE IN .NET
CRITICAL SECTION
WITHOUT HELP
(c)PeterSturm,UniversitätTrier
29
Betriebssysteme
Winter2016
CRITICAL SECTION
• A “sensible” sequence of instructions which may only be
executed by one thread at a time
• Mutual exclusion required inside critical section
• Must be defined by the application
…
• Bracketing by some
Enter() and Leave()
EnterCriticalSection();
Sensible instruction 1;
operations:
Critical
Section
(c)PeterSturm,UniversitätTrier
…
Sensible instruction k;
LeaveCriticalSection();
…
30
Betriebssysteme
Winter2016
CORRECT IMPLEMENTATION
• Mutual exclusion
• At any given time at most one thread is inside
• No deadlocks
• Threads are delayed for a finite time only before entering
• Fairness
• Any thread who wants to enter will enter eventually
• Efficiency
• Threads are not delayed needlessly
• Threads currently not interested shouldn’t do superfluous work
BASIC PROGRAM STRUCTURE
• We assume 2 threads with ids 0 and 1 continuously entering the
critical section:
Different
Implementations
public void Loop ()
{
DateTime start = DateTime.Now;
do
{
EnterCriticalSection();
threads_inside_critical_section++;
if (threads_inside_critical_section > 1)
{
Console.WriteLine("Oops. More than one thread inside critical section");
}
Thread.Sleep(0); // Forces context switch
threads_inside_critical_section--;
LeaveCriticalSection();
} while (((TimeSpan)(DateTime.Now - start)).TotalSeconds < seconds_to_run);
}
• Do not make use of any synchronization support
• No primitives provided by the operating system
• No hardware support
(c)PeterSturm,UniversitätTrier
31
Betriebssysteme
Winter2016
VOLATILE DATA STRUCTURES
• Hardware (CPU, MMU), runtime support, and compiler normally
relax memory consistency to improve performance
• Re-odering memory access as long as program semantics are not altered
• Don’t expect memory to change by side-effects
• Normally, a single thread is assumed
• Unexpected behavior in multi-threaded environments
• Data structures that are accessed concurrently by multiple threads
should be marked volatile
• Nobody will cache these data
• Compiler expects these data to change asynchronously
• Every access will read the memory address
VOLATILE AND C#
• Specific keyword
• volatile bool flag
• Specific static methods in Thread available
• object Thread.VolatileRead ( ref object )
• Thread.VolatileWrite ( ref object, object)
• Various overloads
• The problem with arrays:
• Consider “volatile bool [] flags …”
• Reference to array is marked volatile
• The booleans themselves are not!
• Thread.VolatileRead() and Thread.VolatileWrite() don’t work on
boolean
• Workaround: Integers instead of boolean
• 1 Û true
• Some subsequent examples may look strange L
(c)PeterSturm,UniversitätTrier
32
Betriebssysteme
Winter2016
STARTING POINT
• Empty functions to enter and leave the critical section
• No concurrency control
• Several threads may be inside critical section in parallel
RESULT
(c)PeterSturm,UniversitätTrier
33
Betriebssysteme
Winter2016
STEP 1: ALTERNATING TOKEN
• Implementing a token-based approach
• The thread who owns the token may enter, the other waits
• The token must circulate among the participating threads
ALTERNATING TOKEN
• For each thread
• self = own thread, rival = rival thread
• Solution
private volatile static int turn = 0;
public void EnterCriticalSection ()
{
while (turn != self) /* Busy Wait */;
}
public void LeaveCriticalSection ()
{
turn = rival;
}
(c)PeterSturm,UniversitätTrier
34
Betriebssysteme
Winter2016
RESULT
• No invalidation
• Times inside critical section identical (±1)
COMMENTS
• Mutual exclusion is guaranteed
• It is a fair solution
• Provided any
• It is a non-blocking solution (Busy Waiting)
• Requires preemptive scheduling
• Threads must pass the token actively although they are not
interested in entering the critical section
• Solution doesn’t consider different interest and enter frequency of
all threads involved
(c)PeterSturm,UniversitätTrier
35
Betriebssysteme
Winter2016
STEP 2: SOMEONE INSIDE
• Threads set flag when inside critical section
• Only enter if the rival is not already inside
SOMEONE ABOUT TO ENTER
• For eachprivate
threadstatic
bool[] inside =
new int[2] { 0, 0 };
• self =public
own thread,
rival = rival thread
void EnterCriticalSection
• Solution
{
}
()
while (inside[rival] == 1) /* Busy Wait */ ;
inside[self] = 1;
public void LeaveCriticalSection ()
{
inside[self] = 0;
}
(c)PeterSturm,UniversitätTrier
36
Betriebssysteme
Winter2016
RESULT
• Mutual exclusion condition still invalidated several times
COMMENTS
• Mutual Exclusion not guaranteed
Thread 0:
inside[0] == 0;
...
while (inside[1] == 1) ;
inside[0] = 1;
// Inside Critical Section
Thread 1:
inside[1] == 0;
Context
Switch
...
while (inside[0] == 1) ;
inside[1] = 1;
// Inside Critical Section
• Testing and setting flag is not atomar
• Gets worse with increasing number of threads
(c)PeterSturm,UniversitätTrier
37
Betriebssysteme
Winter2016
STEP 3: SET BEFORE TEST
• Threads express their interest before entering
• Only enter if the rival is not interested too
SET BEFORE TEST
• For eachprivate
threadstatic
bool[] interested =
new int[2] { 0, 0 };
• self =public
own thread,
rival = rival thread
void EnterCriticalSection
• Solution
{
}
()
interested[self] = 1;
while (interested[rival] == 1) /* Busy Wait */ ;
public void LeaveCriticalSection ()
{
interested[self] = 0;
}
(c)PeterSturm,UniversitätTrier
38
Betriebssysteme
Winter2016
RESULT
• No progress after 1 minute! Why?
COMMENTS
• Mutual exclusion guaranteed
• At most one thread (actually 0) inside
• Livelock
Thread 0:
interested[0] = 1;
while (interested[1]==1)
while (interested[1]==1)
while (interested[1]==1)
while (interested[1]==1)
while (interested[1]==1)
...
(c)PeterSturm,UniversitätTrier
Context
Switch
;
;
;
;
;
Thread 1:
interested[1] = 1;
while
while
while
while
while
...
(interested[0]==1)
(interested[0]==1)
(interested[0]==1)
(interested[0]==1)
(interested[0]==1)
;
;
;
;
;
39
Betriebssysteme
Winter2016
STEP 4: I WANT, I DON’T WANT, I WANT …
• Trying to avoid livelock
• In case of imminent livelock release flag for a short period of time
and try again
• Well, it’s still busy waiting, but …
SHORT BREAK
private static bool[] interested =
new int[2] { 0, 0 };
• For each thread
public void EnterCriticalSection ()
• self ={ own thread, rival = rival thread
• Solution
}
interested[self] = 1;
while (interested[rival] == 1) {
interested[self] = 0;
/* Short Break */;
interested[self] = 1;
}
public void LeaveCriticalSection ()
{
interested[self] = 0;
}
(c)PeterSturm,UniversitätTrier
40
Betriebssysteme
Winter2016
RESULT
• Seems to work?
COMMENTS
• Mutual exclusion guaranteed
• Mutual Courtesy
• Threads in lockstep can exhibit livelock-like behavior
Thread 0:
Thread 1:
interested[0] = 1;
while (interested[1]==1)
interested[0] = 0;
/* Short Break */
interested[0] = 1;
while (interested[1]==1)
interested[0] = 0;
/* Short Break */
interested[0] = 1;
...c
interested[1] = 1;
while (interested[0]==1)
interested[1] = 0;
/* Short Break */
interested[1] = 1;
while (interested[0]==1)
interested[1] = 0;
/* Short Break */
interested[1] = 1;
...
(c)PeterSturm,UniversitätTrier
41
Betriebssysteme
Winter2016
THE ALGORITHM BY DEKKER
• Combination of versions 4 and 2
• 4: Set before test, but avoid livelocks by releasing the own flag
again
• 2: Alternating token to resolve conflicts fair
DEKKER: SOURCE CODE
bool [] interested = new bool[2] { false, false };
int turn = 0;
EnterCriticalSection () {
interested[self] = true;
while (interested[rival]) {
if (turn == rival) {
interested[self] = false;
while (turn == rival) /* Busy Wait */ ;
interested[self] = true;
}
}
}
LeaveCriticalSection () {
turn = rival;
interested[self] = false;
}
(c)PeterSturm,UniversitätTrier
42
Betriebssysteme
Winter2016
THE ALGORITHM BY PETERSON
• Improvement of Dekkers’ algorithm
• Conflict is resolved through race condition
• Who made the last write to turn?
PETERSON: SOURCE CODE
bool [] interested = new bool[2] { false, false };
int turn = 0;
EnterCriticalSection () {
interested[self] = true;
turn = rival; // Volatile race condition
while (interested[rival] and (turn == rival)) {
/* Busy Wait */ ;
}
}
LeaveCriticalSection () {
interested[self] = false;
}
(c)PeterSturm,UniversitätTrier
43
Betriebssysteme
Winter2016
ZEIT FÜR VERÄNDERUNGEN!
(c)PeterSturm,UniversitätTrier
44
Betriebssysteme
Winter2016
... WARTEN?
PARALLELISIERENDE COMPILER
• SIMD-artige Probleme (Number Crunching)
• High Performance Fortran (HPF)
• Erweiterung von Fortran 90
• FORALL
• Datenflußanalyse
• Forschungsgebiet
• Alternative Rechnerarchitekturen
(c)PeterSturm,UniversitätTrier
45
Betriebssysteme
Winter2016
PARALLEL LOOP
PRIMZAHLEN
(c)PeterSturm,UniversitätTrier
46
Betriebssysteme
Winter2016
SEQUENTIELL
PARALLEL
(c)PeterSturm,UniversitätTrier
47
Betriebssysteme
Winter2016
STOLPERSTEINE
• Willkürliche Abarbeitungsreihenfolge
• Concurrency-safe?
• Datenabhängigkeiten über Iterationen hinweg!!!
• Seiteneffekte
HAVE A BREAK
• Mehrere Iterationen gleichzeitig aktiv
• Parallel Break
• Alle Iterationen mit kleinerem Index werden noch beendet
• Parallel Stop
• Schnurzpiepegal
(c)PeterSturm,UniversitätTrier
48
Betriebssysteme
Winter2016
BEISPIEL
ES GIBT NOCH MEHR ...
• External Loop Cancellation
• Granularität steuern
• Partitioner
• Minimale und maximale Threadanzahl spezifizierbar
(c)PeterSturm,UniversitätTrier
49
Betriebssysteme
Winter2016
FP
Functional Programming
(c)PeterSturm,UniversitätTrier
50
Betriebssysteme
Winter2016
SINGLE-THREADED
Thread
State
MULTI-PROCESS
Thread
State
(c)PeterSturm,UniversitätTrier
Thread
State
51
Betriebssysteme
Winter2016
MULTI-THREADED
Thread
Shared
Mutable
State
Thread
„IF IT HURTS, STOP DOING IT“
Paul Butcher
Thread
(c)PeterSturm,UniversitätTrier
Shared
Immutable
State
Thread
52
Betriebssysteme
Winter2016
IMMUTABLE
STATE?
IMPERATIV
(c)PeterSturm,UniversitätTrier
53
Betriebssysteme
Winter2016
FUNKTIONAL
(c)PeterSturm,UniversitätTrier
54
Betriebssysteme
Winter2016
CLOJURE
IMPURE FUNCTIONAL LANGUAGE
• „Concurrency-aware mutable variables“
• Imperativ: Mutable ist Standardfall
• Persistenz
• Transaktions-artiges Fortschreiben des Objektzustands
• Vorheriger Zustand während der Änderung zugreifbar
• Software-Transactional Memory
(c)PeterSturm,UniversitätTrier
55
Betriebssysteme
Winter2016
MULTI-THREADED
Thread
Shared
Mutable
State
Thread
MESSAGES
Thread
Thread
State
State
Immutable
(c)PeterSturm,UniversitätTrier
56
Betriebssysteme
Winter2016
ACTORS
FOKUS SUBJEKT: ACTORS
Thread
State
(c)PeterSturm,UniversitätTrier
Thread
State
57
Betriebssysteme
Winter2016
AKTOREN
R
S
Aktiv
S
R
Passiv
ELIXIR
• Läuft auf der „Erlang Virtual Machine“ (BEAM)
• Erlang
• Funktionale Sprache (Ericsson)
• OTP (Open Telecom Platform)
(c)PeterSturm,UniversitätTrier
58
Betriebssysteme
Winter2016
If there’s one lesson we’ve
learned from 30+ years of
concurrent programming,
it is:
Just don’t share state!
Pieter Hintjens
(c)PeterSturm,UniversitätTrier
59
Betriebssysteme
Winter2016
ANSATZ
• Kein „Shared State“ zwischen Threads
• Austausch von Nachrichten
• inproc-Transport
• Support für Thread-Signaling
• PAIR sockets
TPL DATA FLOW
• Actor-artiger Ansatz in .NET
• Zusätzliches Package
• Blocktypen
• Buffer
• TransformBlock ( DataIn, DataOut )
• Broadcast Block
• JoinBlock
• ...
(c)PeterSturm,UniversitätTrier
60
Betriebssysteme
Winter2016
CSP
FOKUS MESSAGE: CSP
Thread
State
(c)PeterSturm,UniversitätTrier
Thread
State
61
Betriebssysteme
Winter2016
CSP
• Communicating Sequential Processes
• Hoare, Process Calculus, 1978
• Channels
• Go
• Clojure, core.async
LAMBDA
ARCHITECTURE
(c)PeterSturm,UniversitätTrier
62
Betriebssysteme
Winter2016
DATENPARTITIONIERUNG
Map-Reduce
NoSQL
(c)PeterSturm,UniversitätTrier
NoSQL
NoSQL
63
Betriebssysteme
Winter2016
• Vertikale Skalierung
• Traditionelle DBMS
SKALIERBARKEIT
• NoSQL-Systeme
• Horizontale Skalierung
APM
Asynchronous Programming Model
(c)PeterSturm,UniversitätTrier
64
Betriebssysteme
Winter2016
FUTURES, PROMISES UND MEHR
ASYNCHRON
• Blockierende Aufrufe meiden
• Ursprung im Bereich „User Interface“
• Ausgangspunkt für nebenläufige Programmierung
(c)PeterSturm,UniversitätTrier
65
Betriebssysteme
Winter2016
.NET
• Verfeinerung und Ausbau von Task, Task<T>
• Task-Ketten
• ...
• Thread Pool
• await
• Synchrone Kapselung eines asynchronen Aufrufs
• Compiler
BEISPIEL
(c)PeterSturm,UniversitätTrier
66
Betriebssysteme
Winter2016
BEMERKUNG ZU .NET
• Nur Einzelaspekte
angesprochen
• Concurrent Collections
• Monitor
• ...
FAZIT
(c)PeterSturm,UniversitätTrier
67
Betriebssysteme
Winter2016
Assassins Creed
(c)PeterSturm,UniversitätTrier
68
Betriebssysteme
Winter2016
... SUCHE GEHT WEITER
• Positiv überrrascht!
• Compiler übernehmen
Hauptlast
• Code-Generierung
• Spannende Zukunft
• Experimentieren
(c)PeterSturm,UniversitätTrier
69
Betriebssysteme
Winter2016
Betriebssysteme
5.SynchronisationmittelsMonitor
Language-basedSynchronization
• Semaphoresand/orothersynchronizationprimitivesare
sufficienttosolveanycomplexsynchronizationproblem
• Butcomplexsolutionsareveryhardtounderstand
• Itisnearlyimpossibletoanticipateanyentangledexecution
ofconcurrentthreadsandtheinfluenceondataconsistency
– Mosthumansaresingle-threaded
(atleastwithrespecttoconsciousnessJ)
• Higherrorprobabilitywithincreasingproblemcomplexity
(c)PeterSturm,UniTrier
1
Betriebssysteme
Winter2016
Higher-LevelAbstractions
• Synchronizationtechniqueswithahigherlevelofabstraction
areneeded
• Synchronizationsupportinprogramminglanguages
– ”Synchronized”inJava
– “lock”inC#
Motivation
•
P.BrinchHansen,T.Hoare,1974
•
Encapsulationofshareddatatogether
withallthefunctionsaccessingthese
data
– Abstractdatatype
– Resemblesinsomesensethenotionof
aclassinobject-orientedlanguages
•
Mutualexclusionbetweenalltheentry
functionsofamonitor
– Implicitmonitorsemaphore
(c)PeterSturm,UniTrier
Monitor M {
Shared Data;
Entry f1 ( Parameter )
: Result {
Statements;
}
...
Entry fn ( Parameter )
: Result {
Statements;
}
}
2
Betriebssysteme
Winter2016
CompilersApplySemaphoresCorrectly!
•Monitor
MutualexclusionguaranteedJ
M {
Shared Data;
Entry f1 ( Parameter )
: Result {
Statements;
}
...
Entry fn ( Parameter )
: Result {
Statements;
}
}
Monitor M {
Shared Data;
Semaphore MonSem(1);
Entry f1 ( Parameter )
: Result {
MonSem.P();
Statements;
MonSem.V();
}
...
Entry fn ( Parameter )
: Result {
MonSem.P();
Statements;
MonSem.V();
}
}
Producer/Consumer?
(c)PeterSturm,UniTrier
3
Betriebssysteme
Winter2016
OutlineofBuffer
public class Buffer
{
public Buffer ( int n )
{
}
/// Inserts another good into the buffer.
/// May block until free space is available.
public void Produce ( int good )
{
}
}
/// Consumes a good stored inside the buffer.
/// May signal blocked producer threads.
public int Consume ()
{
return 42;
}
public class Producer
{
public Producer ( Buffer b )
{
buffer = b;
my_id = this.GetHashCode();
ThreadStart ts = new ThreadStart(Run);
my_thread = new Thread(ts);
my_thread.Start();
}
Producer(C#)
private void Run ()
{
Console.WriteLine("Producer {0}: started ...",my_id);
int good = this.GetHashCode() * 1000000;
while (true)
{
buffer.Produce(good);
Console.WriteLine("Producer {0}: good {1} stored",my_id,good);
good++;
}
}
}
(c)PeterSturm,UniTrier
private Buffer buffer;
private Thread my_thread;
private int my_id;
4
Betriebssysteme
Winter2016
Consumer(C#)
public class Consumer
{
public Consumer ( Buffer b )
{
buffer = b;
my_id = this.GetHashCode();
ThreadStart ts = new ThreadStart(Run);
my_thread = new Thread(ts);
my_thread.Start();
}
private void Run ()
{
Console.WriteLine("Consumer {0}: started ...",my_id);
while (true)
{
int good = buffer.Consume();
Console.WriteLine("Consumer {0}: good {1} retrieved",my_id,good);
}
}
}
private Buffer buffer;
private Thread my_thread;
private int my_id;
TheBuffer(C#)
public class Buffer
{
public Buffer ( int n )
{
this.n = n;
slots = new int[n];
mutex = new Semaphore(1);
slots_available = new Semaphore(n);
goods_available = new Semaphore(0);
}
…
}
(c)PeterSturm,UniTrier
private
private
private
private
private
private
private
int n;
int [] slots;
int free = 0;
int used = 0;
Semaphore mutex;
Semaphore slots_available;
Semaphore goods_available;
public void Produce ( int good )
{
slots_available.P();
mutex.P();
slots[free] = good;
free = (free+1) % n;
mutex.V();
goods_available.V();
}
public int Consume ()
{
goods_available.P();
mutex.P();
int good = slots[used];
used = (used+1) % n;
mutex.V();
slots_available.V();
return good;
}
5
Betriebssysteme
Winter2016
TheMonitorBuffer(C#)?
public monitor Buffer
{
public Buffer ( int n )
{
this.n = n;
slots = new int[n];
slots_available = new Semaphore(n);
goods_available = new Semaphore(0);
}
…
}
private
private
private
private
private
private
int n;
int [] slots;
int free = 0;
int used = 0;
Semaphore slots_available;
Semaphore goods_available;
public void Produce ( int good )
{
slots_available.P();
slots[free] = good;
free = (free+1) % n;
goods_available.V();
}
public int Consume ()
{
goods_available.P();
int good = slots[used];
used = (used+1) % n;
slots_available.V();
return good;
}
ConditionVariable
CV:
Queue(q)
TCB
TCB
TCB
• Synchronizationinsidethemonitor
– CV.Wait()
• Callingthreadwillbealwaysblocked
• Monitorwillbefreeagain
– CV.Signal()
• SomeotherthreadkblockedatCVwillbereadyagain
• kmustcompeteformonitorentranceagain
• DifferentvariantsofSignal()possible
(c)PeterSturm,UniTrier
6
Betriebssysteme
Winter2016
SolutionwithMonitor
• Monitorisusedtoimplementtheboundedbuffer
• Conditionvariablesareusedtosynchronizeproducersand
consumersinsidethemonitor
Monitor Buffer {
const int max_items = 42;
Item[] items = new Item[max_items];
int free = 0;
int used = 0;
int n_items = 0;
ConditionVariable some_free;
ConditionVariable some_used;
public void Produce ( Item i );
}
public Item Consume ();
void Produce ( Item i )
public void Produce ( Item i ) {
// Wait if no free slot left in buffer
while (n_items == max_items)
some_free.Wait();
// Insert item
n_items++;
items[free] = i;
free = (free + 1) % max_items;
}
(c)PeterSturm,UniTrier
// Signal to waiting consumer arival of item
some_used.Signal();
7
Betriebssysteme
Winter2016
Item Consume ()
public Item Consume () {
// Wait if no item available in buffer
while (n_items == 0)
some_used.Wait();
// Get item
n_items--;
Item result = items[used];
used = (used + 1) % max_items;
}
// Now producers may store another item
some_free.Signal();
return result;
Noticetheasymmetric
usageofthecondition
variables
GeneralArchitectureofaMonitor
•
EQ
– Threadtryingtoenterthe
monitor
CQ1
•
•
Monitor
Variables
SignallingQueue(SQ)
– Anyactivethreadissuingasignal
operationonsomecondition
queuesmustenterthisqueue
SQ
WQ
ConditionQueues(CQ)
– Foreachconditionvariablea
queueforallthewaitingthreads
CQ2
CQk
EntryQueue(EQ)
•
SignaledQueue(WQ)
– Threadsawaitingmonitor
re-entranceafterreceiving
asignal
Exit
Blocked Thread
Active Thread (only 1)
(c)PeterSturm,UniTrier
8
Betriebssysteme
Winter2016
ActiveThreadLeavesMonitor
EQ
•
Who’snext?
•
Anynewthreadoutsidewhowants
toenter?(EQ)
•
Somethreadwhohasbeensignaled
inaconditionvariable?
CQ1
CQ2
CQk
– ThreadhasleftCQibecauseof
signalandiswaitsforthemonitor
againatthecommonentrance
Monitor
Variables
SQ
WQ
•
SQisaspecialcase
– Someversionsofsignalblockthe
signalingthreadandfavorthe
signaledthreadagain
Exit
MonitorClassifikation
• AssigningdifferentprioritiestoqueuesEQ,SQundWQ
(see[Buhretal1995])
• Prioritymeans,ifthreadsarewaitingonallthesequeues,
threadsinqueueswithhigherpriorityarefavorized
(c)PeterSturm,UniTrier
EQp = WQp < SQp
Wait and Notify
EQp = SQp < WQp
Signal and Wait
EQp < WQp < SQp
Signal and Continue
EQp < SQp < WQp
Signal and Urgent Wait
9
Betriebssysteme
Winter2016
Example“SignalandContinue”
EQ
CQ1
CQ2
CQk
Monitor
Variables
SQ
WQ
•
Threadinsidemonitorexecutesis
signalingconditionvariableCQ2
•
Conceptually,activethreadmust
enterSQ
•
TheprioritysettingsfavorSQagain
•
Nowactivethreadisleaving
monitor
•
SQisempty,soWQisnext
•
Nowthisthreadisleavingtoo
•
SinceSQandWQareemtpy,anew
threadmayenter
Exit
Blocked Thread
Active Thread (only 1)
Implementationof“SignalandContinue”
•
Priorities
•
Datastructures
–
–
–
–
–
EQp<WQq<SQq
Semaphorec.sforeachconditionvariablec
Counterc.ccountsthenumberofthreadsblockedonc
Similarforsignaledqueue
Nosignallingqueuerequired
Entry fk (...) {
P(MonSem);
...
if (w.c > 0)
V(w.s);
else
V(MonSem);
}
(c)PeterSturm,UniTrier
Wait ( Condition c ) {
c.c += 1;
if (w.c > 0)
V(w.s);
else
V(MonSem);
P(c.s);
c.c -= 1;
w.c += 1;
P(w.s);
w.c -= 1;
}
Signal ( Condition c ) {
if (c.c > 0)
V(c.s);
}
10
Betriebssysteme
Winter2016
Example“SignalandUrgentWait”
EQ
CQ1
CQ2
CQk
Monitor
Variables
SQ
WQ
Exit
•
Threadinsidemonitorexecutesis
signalingconditionvariableCQ2
•
ActivethreadmustenterSQ
•
TheprioritysettingsfavorWQ,so
ownershipchangestothreadinWQ
•
Whenthisthreadleavesmonitor…
•
…thesignalingthreadwillenter
again
•
Andwhenthisthreadleavesthe
monitor…
•
…anotherthreadfromEQmay
enter
Blocked Thread
Active Thread (only 1)
The3MostCommonSignal()
• SignalandContinue
– Signalingthreadsremainsinsidemonitor
– Atmostoneblockedthreadisfreed
– Foundinthemajorityofimplementations
• Signaland(Urgent)Wait
– Signalingthreadwillbeblocked
– Signaledthreadisresumed
– Quiteoften,signaledthreadre-entersmonitorjusttoleaveit
• BroadcastSignalandContinue
– Signalingthreadremainsinsidemonitor
– Allblockedthreadsarefreed
– Manythreadswakeupjusttosleepagain
(c)PeterSturm,UniTrier
11
Betriebssysteme
Winter2016
Reader/Writer?
(c)PeterSturm,UniTrier
12
Betriebssysteme
Winter2016
Realtime Systems
Realtime?
• Functional requirements
– Software has to do it‘s job!
• Non-functional requirements
– Within given time constraints
(c)PeterSturm,UniversityofTrier
1
Betriebssysteme
Winter2016
Soft Realtime
• Violating a time constraint is annoying
• Examples
– Digital phone switch
– Multimedia
Hard Realtime
• Violating a time constraints may end in a disaster
• Examples
– Controling some critical chemical reaction
– Anti-lock braking system (ABS)
– Fly by wire in planes (e.g. Airbus)
(c)PeterSturm,UniversityofTrier
2
Betriebssysteme
Winter2016
OS Issues
• Realtime scheduling
• Dedicated functionality
• Communicating deadlines
How to become a RT OS?
(c)PeterSturm,UniversityofTrier
3
Betriebssysteme
Winter2016
Requirements
• Minimal interrupt latency
• Don‘t lose interrupts
• Minimal context switch latency
• No unexpected delays
– Memory locking
• Guarantees
– Upper bound for input stimulus to output response
• Size
Example OS
• Most are for embedded systems
– Symbian OS, Nokia OS, ...
• Others
– QNX, VxWorks, LynxOS, ...
• RTLinux
– Multi-Environment Real-Time (MERT)
– Microkernel with fully preemptive Linux OS (process)
• Windows CE
(c)PeterSturm,UniversityofTrier
4
Betriebssysteme
Winter2016
Real-Time Scheduling
• Meet application-specific time constraints
• Determining program characteristics and deriving
time constraints is very hard
• Worst case assumptions
• Scheduling depends on time constaints
Modeling Realtime Activities
• Time constraints
– Ready time r
• Earliest execution time
– Deadline d
De
r
d
• Activity must be finished
– Execution time ∆e
• Problem
– How to determine ∆e
– Worst case assumption
– Bad utilization
(c)PeterSturm,UniversityofTrier
5
Betriebssysteme
Winter2016
Periodic Activities
De
• Period ∆p
De
Dh
r1
r2=d1
r3=d2
– Frequency
• Phase ∆h
– Initial offset in execution
rk = Dh + ( k - 1) Dp
d k = Dh + kDp = rk +1
• Constraints can be
derived
Successful Completion
• Any activity must be completed
– Start time s: Actual begin of execution
– Completion time c: Actual end of execution
• ... within time constraints
– Not to early: "k : rk £ sk
– Not to late: "k : ck £ d k
(c)PeterSturm,UniversityofTrier
6
Betriebssysteme
Winter2016
Preemption
De
r
s
c
d
c
d
Without Preemption
r s
With Preemption
Static/Dynamic Scheduling
• Static
– All constraints are known
– no surprises during execution
– limited adaptibility
• Dynamic
– Some constraints known at run-time only
– Typically, dynamic creation of threads
– Guarantees hard to meet
(c)PeterSturm,UniversityofTrier
7
Betriebssysteme
Winter2016
Explicit/Implicit Scheduling
• Explicit
– Complete scheduling plan available at run-time
– Offline-Scheduling
– Scheduling = Table access via time index
• Implicit
– Scheduling rules such as priorities
Best Effort
• Don‘t consider time constraints at all
– Use normal scheduling strategies
– Application doesn‘t have to define constraints
• Design hardware (and software)
to keep up with maximum demand
(c)PeterSturm,UniversityofTrier
8
Betriebssysteme
Winter2016
Consequences
• Meeting time constraints not guaranteed
• Maybe useful
– Some soft real-time systems
• Widespread usage
Earliest Deadline First (EDF)
• Assign CPU to thread with next deadline
• Dynamic priorities
• Preemptive and non-preemptive versions
(c)PeterSturm,UniversityofTrier
9
Betriebssysteme
Winter2016
EDF optimal?
• Non-preemptive EDF is not optimal
– Although a plan that meets all deadlines exists, nonpreemptive EDF may not find it?
• Preemptive EDF is optimal
– If there is a plan, preemptive EDF will find it
– Neglect time for context switches
Example
(c)PeterSturm,UniversityofTrier
10
Betriebssysteme
Winter2016
SCHED_DEADLINE
Rate Monotonic Scheduling
• Implicit scheduling with fixed priorities
• Theory by Liu and Layland (1973)
– Periodic activities
– Period definies priority
High Frequency = High Priority
(c)PeterSturm,UniversityofTrier
11
Betriebssysteme
Winter2016
RMS (contd.)
High Frequency = High Priority
• Somewhat counterintuitive
• Of no influence
– Importance of threads
– Execution time (De)
• Of course, thread with high frequency
can’t have a long De
RMS Assumptions
• Ready time starts with period
• Deadline ends with period
• Threads don‘t suspend themselves
– No voluntary blocking system call
• Threads are preemtable
• Switching & scheduling overhead is neglectable
• Threads are independent
(c)PeterSturm,UniversityofTrier
12
Betriebssysteme
Winter2016
Priority
Important = High Priority?
• Important thread with low frequency
• Increasing probability that low priority thread with
high frequency miss their deadline
Priority
High Frequency = High Priority
• High frequency = Small execution time (De < Dp)
• Increasing frequency = decreasing delay
– Only interrupted by threads with even higher frequency
• Cutting up of threads with low frequency
– More context switches (still neglectable?)
(c)PeterSturm,UniversityofTrier
13
Betriebssysteme
Winter2016
Critical Instance
•
tL has low priority
•
tH has high priority
•
Can TL meet its deadline?
•
r(tL) = r(tH)
– Critical Instance
•
r(tL) < r(tH)
– Simple movement
– No influence on deadline of tL
•
r(tH) < r(tL)
– Easier for tL to meet its deadline
Response Time
• Response Time = Completion Time – Ready Time
• Ready time depends on frequency and execution
time of threads with higher priorities
• No delay for thread with highest priority
c0 - r0 = De0
• For all the others
(c)PeterSturm,UniversityofTrier
c p - rp <
æ ê Dp p ú
ö
ç
D
×
e
å ê ú k ÷ø + Dep
0£ k < p è ë Dpk û
14
Betriebssysteme
Winter2016
RMS Scheduling Criterion
• For a set of n periodic threads is
Dek
k =1 Dpk
n
Un = å
UMn
the utilization of the
system
• RMS leads to an executable plan, if
1
n
U n < UM n = n × (2 - 1)
(c)PeterSturm,UniversityofTrier
15
Betriebssysteme
Winter2016
Dateisysteme
Peter Sturm
Universität Trier
Aufgaben
• Persistente Daten
• Information
• Organisation
©PeterSturm,UniversitätTrier
1
Betriebssysteme
Winter2016
• 5 MByte Festplatte wird
mit dem Gabelstapler
verladen (1956)
©PeterSturm,UniversitätTrier
2
Betriebssysteme
Winter2016
Beispiel Seagate
• Liefert 1979 erste Festplatte aus
• ST506, 5 MB Daten, $1500
• April 2008
• 1 Milliarde Laufwerke ausgeliefert
• Prognostiziert 2 Milliarden in 5 Jahren
• Kummulative ausgelieferte Speicherkapazität seit
1979
• 79.000.000 Terabytes
• 7.5 Ÿ 1018 Bytes (75 Exabyte)
• 1.5 TByte Platten (3.5 Zoll)
Rechenbeispiele
• Schrift
• Brockhaus paßt auf eine DVD
• Lebenslange Audioaufzeichnung
• 32 Kbit pro Sekunde
• 120 GByte pro Jahr
• 9.6 TByte bei 80 Jahren Lebenserwartung
• Ein Leben in Einzelbildern
• Microsoft SenseCam, 1 Tag = 7 -10 MByte
• Lebenslanges Filmarchiv
• 4 GByte pro Stunde (DVD-Qualität)
• 4 Stunden pro Tag (im Alter 0 .. 80)
• 456 TByte
©PeterSturm,UniversitätTrier
3
Betriebssysteme
Winter2016
Microsoft SenseCam
• Digitalkamera, die selbständig Bilder macht
• Wahl geeigneter Zeitpunkte
• Sensoren
• Lichtintensität
• Farbsensoren
• Infrarot
(Körperwärme)
• Temperatur
• Beschleunigung
(über mehrere Achsen)
Terabyte
• Aktuell gängige Größe
1024 4 = 1024 ⋅1024 ⋅1024 ⋅1024 = 1.099.511.627.776
• Wieviel ist das?
• Fußballfeld voller Smarties?
©PeterSturm,UniversitätTrier
4
Betriebssysteme
Winter2016
126Meter
Probleme
©PeterSturm,UniversitätTrier
5
Betriebssysteme
Winter2016
Moore’sche Gesetz
• Selbsterfüllende Prophezeiung
• Vorgabe an den Fortschritt im Entwicklungsprozeß
• Laut Intel mindestens bis
2029 gültig!
Intel
Folgen
• 2029 – 2016 ≈ 16 = 8Ÿ 2 è Steigerung um Faktor
256
• Gilt bestimmt für Hauptspeicher
• 1-4 TByte pro PC realistisch
• Festplatten ebenfalls
• 500 TByte bis 1 PByte pro Platte (3.5 Zoll) erreichbar
• Smartphone mit 500 Tbyte? Möglich!
• Sollen wir so weiter machen wie bisher?
©PeterSturm,UniversitätTrier
6
Betriebssysteme
Winter2016
Hibernate
• Retten des Hauptspeicherinhalts auf Festplatte
• System “schneller” wieder fortführbar
• Einfach den Hauptspeicherinhalt wieder herstellen
• Sinnvoll bei 8 GB? 32 GB? 1 TByte?
• Ja bei nicht-flüchtigem RAM
• Nein sonst
Speichermenge beherrschen?
• Hierarchische Ordnungsprinzipien für Menschen nur
bedingt geeignet
• … und wer noch daran glaubt, weiß es nur noch nicht J
• Subjektive Erkenntnis
• Kurz vor der Organisationskatastrophe
• Entartete Verzeichnisstruktur
• Ja …
• mag sein, daß nur ich unfähig bin!
OLD
OLD
©PeterSturm,UniversitätTrier
7
Betriebssysteme
Winter2016
Wiederfinden?
• Finden Sie alles wieder?
• Ich nicht L
• 14 Jahre gewachsenes Homeverzeichnis: > 1 TB
• Ich habe ausgedruckte Beweise, daß bestimmte
Dateien mal existiert haben
• dümpeln vielleicht in irgendwelchen Archiv-CDs rum
• Droht digitaler Alzheimer?
• Ja …
• im kommerziellen Umfeld wird sauber gearbeitet: hier
nicht!
Geräte-Allerlei
• Eine Vielzahl an angeschlossenen physischen
Speichermedien prägen das Bild!
• PC: Sticks, Festplatten, portable Platten, …
• Backend: Speicherplatz für Zig-TByte oder gar -PByte Daten
• Einzelmedium häufig isoliert
• Viele Entscheidungen beeinflussen Systemleistung
• Welches Dateisystem für welches Gerät?
• Kleine Änderung – große Wirkung
• Ja …
• Im professionellen Bereich gibt es Lösungen (z.B. Volume
Manager)
©PeterSturm,UniversitätTrier
8
Betriebssysteme
Winter2016
Anwendungsentwicklung
Informationenim
Hauptspeicher
(Flüchtig)
Informationenauf
externemSpeicher
(Nichtflüchtig)
• Zwei Welten
• Externer Speicher
• Einfacher Dateizugriff
• SQL-Queries gegen Datenbanken
• Interner Speicher
• Container-Klassen mit entsprechenden Zugriffsmöglichkeiten
Beispiel Container-Klassen
©PeterSturm,UniversitätTrier
9
Betriebssysteme
Winter2016
Dateisysteme
Typische Dateinutzung
• Dateien sind klein oder sehr groß
• Lesender Zugriff überwiegt
• Sequentieller Zugriff dominiert
• (Dateien werden selten oder nie gelöscht)
• Einige Dateien werden von vielen Nutzern verwendet
• Dabei überwiegt lesender Zugriff
• “Make the common case fast”
• Sequentieller lesender Zugriff auf Dateien
• Caching und Read Ahead sinnvoll
©PeterSturm,UniversitätTrier
10
Betriebssysteme
Winter2016
Meta Data
• File information (inode)
• Size, owner, access rights, timestamps
• Where are the blocks on disk
• Directory information
• Content, owner, access rights, timestamps
• Device information
• root directory
• Free blocks
• Bad blocks
Requirements
• Minimize time-consuming head movement
• Store file data & meta-data in close neighborhood
• Collect mutiple disk requests and optimize movement
• Cluster blocks consecutive blocks of a file phyiscally
• Improve read/write performance
• Utilize caching agressively (disk & OS)
• Exploit striping and mirroring
• Keep pace with increasing disk capacity
• “Disk usage is like an ideal gas, which takes up every
available space”
• Deal with more and more files
• Recovery in case of system failure must be fast
©PeterSturm,UniversitätTrier
11
Betriebssysteme
Winter2016
Functions
• Formatting and initializing media
• Create initial content to access media
• Keeping track of bad blocks
• Recognize bad blocks and exclude them from future use
• Managing of meta-data
• Small set of data but high update frequency
• Storing and retrieval of files
• Sequential reading and writing
• Positioning of file pointer
• Mapping files into virtual address space
• Security
• Who‘s allowed to access a file?
Hierarchical Structure
Vir tual Filesystem
Physical Filesystem
Volume Access
LogicalVolumes
Logical Volume Management
PhysicalVolumes(Disks)
©PeterSturm,UniversitätTrier
12
Betriebssysteme
Winter2016
In Place vs. Log
• Sometimes high update frequency
• e.g. every access changes some timestamps
• Small updates
• 4 bytes timestamp
• Cache changes might
lead to inconsistencies
• How to update
• In place
• Log-based
Classification
Data
UpdateinPlace
Log
MetaData
UpdateinPlace
©PeterSturm,UniversitätTrier
Traditional filesystems
ext2, FAT, …
Journaling
filesystems
ext4, NTFS, HFS,
reiserfs, XFS, …
Log
unknown
Log-based
filesystems
ZFS, btfs, …
13
Betriebssysteme
Winter2016
Linux
Linux 4.3/fs
9p adfs affs afs autofs4 befs bfs btrfs
cachefiles ceph cifs coda configfs cramfs
debugfs devpts dlm ecryptfs efivarfs efs
exofs exportfs ext2 ext4 f2fs fat freevxfs
fscache fuse gfs2 hfs hfsplus hostfs hpfs
hugetlbfs isofs jbd2 jffs2 jfs kernfs lockd
logfs minix ncpfs nfs nfs_common nfsd nilfs2
nls notify ntfs ocfs2 omfs openpromfs
overlayfs proc pstore qnx4 qnx6 quota
ramfs reiserfs romfs squashfs sysfs sysv
tracefs ubifs udf ufs xfs
©PeterSturm,UniversitätTrier
14
Betriebssysteme
Winter2016
./fs/<fsdir>
find linux-4.3/fs/* -maxdepth 0 -type d |
xargs -n 1 -J dir find dir -name "*.[ch]" -exec cat {} \; |
wc
• Linux 4.3
• 1.084.731 Zeilen von 4.614.490 Zeilen Kernel
Zeilen Sourcecode
0
20000
40000
60000
80000
100000
120000
9p
adfs
affs
afs
autofs4
befs
bfs
btrfs
cachefiles
ceph
cifs
coda
configfs
cramfs
debugfs
devpts
dlm
ecryptfs
efivarfs
efs
exofs
exportfs
ext2
ext4
f2fs
fat
freevxfs
fscache
fuse
gfs2
hfs
hfsplus
hostfs
hpfs
hugetlbfs
isofs
jbd2
jffs2
jfs
kernfs
lockd
logfs
minix
ncpfs
nfs
nfs_common
nfsd
nilfs2
nls
notify
ntfs
ocfs2
omfs
openpromfs
overlayfs
proc
pstore
qnx4
qnx6
quota
ramfs
reiserfs
romfs
squashfs
sysfs
sysv
tracefs
ubifs
udf
ufs
xfs
©PeterSturm,UniversitätTrier
15
Betriebssysteme
Winter2016
ext2
• The original Linux filesystem
• Origin was Minix filesystem
• Extended filesystem (inefficient extension)
• 2nd Extended filesystem (since 1994)
• Properties
•
•
•
•
Selectable block size between 1024 and 4096 bytes
Selectable number of inodes per partition
Clustering of blocks
Preallocation of file blocks (enlargement)
Structure
BootBlock
BlockGroup0
Group
Descriptors
Superblock
1
n
BlockGroupn
DataBlock
Bitmap
1
Inode
Bitmap
1
Inode
Table
DataBlocks
m
• Reason for block groups?
• Maximum size of block group:
• Data Block Bitmap = 1 Block
• 8 MB (1 KB blocks) up to 128 MB (4 KB blocks)
• Superblock and group descriptors are replicated in each group
• Kernel will access block group 0 only
©PeterSturm,UniversitätTrier
16
Betriebssysteme
Winter2016
• Total number of inodes
Superblock
• Block size
• Size of overall filesystem in blocks
• Number of reserved blocks
• Only accessible by root processes
• Accessing an otherwise full filesystem
• Number of free blocks and free inodes
• Characteristics of block groups
• Statistics
• Timestamps (Last mount operation, Last write, Last filesystem check)
• Mount statistics (Number of mount operations, Maximum mounts before
check)
• Status flag
• 0 mounted or missed unmount, 1 cleanly unmounted, 2 Filesystem has errors
ext3 & ext4
• Journaling der Metadaten
• Ext4
•
•
•
•
Größere Platten (1 EB)
Größere Dateien (16 TB statt 16 GB)
Größere Directories
Checksums, Delayed allocation, …
©PeterSturm,UniversitätTrier
17
Betriebssysteme
Winter2016
Flash
• Floating Gate FETs
• Gate von Isolator umgeben
• Hält Ladung sehr lange
• Ladung beeinflußt Verhalten
©PeterSturm,UniversitätTrier
18
Betriebssysteme
Winter2016
Besonderheiten
• Hohe Spannungen beim Ändern
• 1 kann zu 0 werden
• Block-basiertes Löschen
• 0 wieder zu 1
• Memory Wear
• 105 bis 106 Erase-Zyklen
• Flash Translation Software Layer (FTL)
• Read Disturb (NAND)
©PeterSturm,UniversitätTrier
19
Betriebssysteme
Winter2016
Recht verbreitet …
Flash File Systems
©PeterSturm,UniversitätTrier
20
Betriebssysteme
Winter2016
Update in Place L
Update in Place L
©PeterSturm,UniversitätTrier
21
Betriebssysteme
Winter2016
Update in Place L
Update in Place L
©PeterSturm,UniversitätTrier
22
Betriebssysteme
Winter2016
Update in Place L
Update in Place L
©PeterSturm,UniversitätTrier
23
Betriebssysteme
Winter2016
Update in Place L
Update in Place L
©PeterSturm,UniversitätTrier
24
Betriebssysteme
Winter2016
Update in Place L
Update in Place L
©PeterSturm,UniversitätTrier
25
Betriebssysteme
Winter2016
Log-Based J
Log-Based J
©PeterSturm,UniversitätTrier
26
Betriebssysteme
Winter2016
Log-Based J
Log-Based J
©PeterSturm,UniversitätTrier
27
Betriebssysteme
Winter2016
Log-Based J
Log-Based J
©PeterSturm,UniversitätTrier
28
Betriebssysteme
Winter2016
Indexstrukturen
Indexstrukturen
©PeterSturm,UniversitätTrier
29
Betriebssysteme
Winter2016
Indexstrukturen
Indexstrukturen
©PeterSturm,UniversitätTrier
30
Betriebssysteme
Winter2016
Indexstrukturen
Indexstrukturen
©PeterSturm,UniversitätTrier
31
Betriebssysteme
Winter2016
Walking Trees
DerKampfderHäuptlinge
Flash Friendly File System
©PeterSturm,UniversitätTrier
32
Betriebssysteme
Winter2016
Fight walking trees
©PeterSturm,UniversitätTrier
33
Betriebssysteme
Winter2016
Fight Walking Trees
MappingTable
… noch mehr
• Optimimiertes Layout
• Multi-Head Logging
• Hot/Cold data
• Adaptive Logging
• Role-Forward Recovery
©PeterSturm,UniversitätTrier
34
Betriebssysteme
Winter2016
DiagrammeausdemangegebenArtikel
Andere Dateisysteme
• BTRFS
• Wächst und gedeiht
• Bootbar, Software RAID
• NILFS2
• New Implementation of a Log-based File System
• XFS
• In vielen Benchmarks das Schnellste
• Parallel I/O
• OCFS2
• Cluster-Dateisystem (für RDBMS-Cluster)
©PeterSturm,UniversitätTrier
35
Betriebssysteme
©PeterSturm,UniversitätTrier
Winter2016
36
Betriebssysteme
Winter2016
ZFS
• SUN Microsystems
• Vorreiter im Bereich logbasierter Dateisysteme
• Entwickelt für Solaris 10 / OpenSolaris
• ZFS setzt den “State of the Art” geschickt um
• Vollständige Neuentwicklung
• 128 Bit Dateisystem
“Populating 128-bit file systems would exceed the
quantum limits of earth-based storage. You couldn't
fill a 128-bit storage pool without boiling the
oceans.” (Jeff Bonwick, Chief Developer ZFS)
Kilauea
©PeterSturm,UniversitätTrier
37
Betriebssysteme
Winter2016
Eckdaten
• Kernziele
• Transaktional
• Integriertes Volume-Management
• Einfache Bedienung und Administration
• Pooled Storage
• Alle Speichersysteme werden in einem Pool verwaltet
• Selbst Hardware-RAID ist prinzipiell nicht mehr nötig
• Ende-zu-Ende Datenintegrität
•
•
•
•
Fehlerisolation zwischen Daten und Prüfsumme
Erkennt exotische Fehlersituationen (Phantom Writes, …)
Datenredundanz und Selbstheilung
RAID-Z
Grundstruktur
ZFSFilesystem
Snapshot
Volume
Traditionelles
Dateisystem
(z.B.UFS)
DataSets
DataSetManagement
Pools
PoolManagement
Disks
©PeterSturm,UniversitätTrier
38
Betriebssysteme
Winter2016
Charakteristische Größen
• Wortlänge:
128 Bit
• Höchstanzahl Dateien:
248
• Größe Dateisystem (max.):
16 EB
• Größe Datei (max.):
16 EB
• Größe Einzelpool (max.):
3×1023 PB
• Höchstanzahl Attribute / Datei:
256
• Höchstanzahl Geräte in zPool:
264
• Dateisysteme in zPool:
264
• zPools in System:
264
Datenintegrität
• Alle Operationen copy-on-write / transaktionsbasiert
• Daten auf Platte immer konsistent
• Kein Journaling notwendig
1.
2.
3.
©PeterSturm,UniversitätTrier
4.
39
Betriebssysteme
Winter2016
Datenintegrität II
• Ende-zu-Ende-Prüfsummen
• Daten und Metadaten
• 256 Bit (fletcher2 u.a.)
• Prüfsumme in übergeordnetem Blockpointer
Adresse
Adresse
Prüfsumme
Prüfsumme
Adresse
Adresse
Prüfsumme
Prüfsumme
Daten
Daten
Datenintegrität III
• Automatische Erkennung und Korrektur korrupter
Daten
• ‘Selbst-Heilung’ der Daten
• Disk Scrubbing
Applikation
Applikation
Applikation
ZFS
(Mirror)
ZFS
(Mirror)
ZFS
(Mirror)
©PeterSturm,UniversitätTrier
40
Betriebssysteme
Winter2016
Redundant Arrays of
Independent Disks (RAID)
• 6 Levels
•
•
•
•
•
•
•
RAID 0: Striped
RAID 1: Mirrored
RAID 2: Striped+ ECC
RAID 3: Striped+ Parity
RAID 4: Huge stripes + Parity
RAID 5: Huge stripes + Rotating Parity
RAID 6: RAID 5 + additional parity
A
B
C
D
AA
B
C
D
• Most common are RAID 0,1,5 and
combinations (RAID 10 = 1 + 0)
CD
AB
• Favor huge writes
• Overhead 1/(n-1) for ndisks
C’D’
A’B’
• Small writes are expensive
•
•
•
•
Read data
Write data
Read parity
Write parity
AA
BA
C
Parity
Raid 5 und Raid 6
1
0
1
1
0
0
1
1
EvenParity
• Raid 5
• Feste Stripe-Größe für schnelle Positionsberechnung
• Große Writes anstreben
• Anfällig in der Recoveryphase
• Raid 6
• Zusätzlicher Parity-Block macht Recoveryphase robust
• Write Hole
• Stromausfall zwischen Schreiben von Daten- und Parity-Block
• HW-Controller verwenden NVRAM (z.B. Batteriepufferung)
©PeterSturm,UniversitätTrier
41
Betriebssysteme
Winter2016
Raidz / Raidz2
• In ZFS integrierte Raid-Schemata
• Raidz (= Software Raid5)
• Atomares Copy-On-Write
• Stripes unterschiedlicher Länge
• d.h. nur Full-Stripe-Writes
• Parity lesen entfällt
• Raidz2 ähnelt in seiner Funktion Raid6
Schnappschüsse
und Klone
©PeterSturm,UniversitätTrier
42
Betriebssysteme
Winter2016
Snapshots
• Read-only Kopie eines Dateisystems oder
Volumes
• Platzeffizient (Copy-on-Write)
• Snapshot-Name:
filesystem@snapname
volume@snapname
Clones
• Beschreibbares Volume oder Dateisystem
• Entsteht aus Snapshots (Copy-On-Write)
• Snapshots möglich
• Anwendungsbeispiel
• Boot Environment von OpenSolaris
©PeterSturm,UniversitätTrier
43
Betriebssysteme
Winter2016
Benutzung
Administration
• Einfache Administration
• Zwei zentrale Kommandos
• zpool
• Erzeugen, Verwalten und Löschen von Pools
• Zustandsinformation
• Verlaufslog
• zfs
• Erzeugen, Verwalten und Löschen von Datasets
• Schnappschüsse und Klone
©PeterSturm,UniversitätTrier
44
Betriebssysteme
Winter2016
ZFS Datasets sind “kostengünstig”
• Fein-granulare Nutzung empfohlen
• Jedes Benutzer-Account = eigenes Dateisystem
• Jeder besonders zu behandelnde Teilbaum
• Vorteile
• Weiterhin einzeln verwalt- und konfigurierbar
• Zuteilung vorhandener Pool-Ressourcen
# zpool create home mirror disk1 disk2
Beispiel
# zfs create home/volker /export/home/volker
# zfs create home/michael /export/home/michael
# zfs create home/annett /export/home/annett
# zpool add home mirror disk3 disk4
# zfs compression=on home/michael
# zfs create home/michael@donnerstag
# zfs quota=42g home/volker
# zfs reservation=10g home/annett
# zfs clone home/michael@donnerstag home/tmp
# zfs send home/michael@donnerstag | ssh sturm@...
©PeterSturm,UniversitätTrier
45
Betriebssysteme
Winter2016
Metadaten
Repositories
Finden
Daten
Daten
Daten
Daten
Metadaten
Metadaten
Metadaten
Metadaten
• Datenbank speichert
• … alle vorhandenen Metadaten
• … zusätzlich inhaltsbezogene Keywords
• Ermitteln spezifische Plugins abhängig vom
Dateityp
• Ereignisgesteuerter, asynchroner Aufruf bei
Dateiänderung
Repository
• Komplexe Suchanfragen formulierbar
©PeterSturm,UniversitätTrier
46
Betriebssysteme
Winter2016
Beispiel Spotlight
(P)LINQ
©PeterSturm,UniversitätTrier
47
Betriebssysteme
Winter2016
LINQ
• Language integrated Query
• Bestandteil von .NET 3.5
• SQL-ähnliche Queries auf Container-Klassen und alle
mengenorientieren Datenstrukturen
• Zusätzliche Indirektionsstufe
Informationenim
Informationenauf
EinheitlicherZugriffaufflüchtigundpersistent
Hauptspeicher
externemSpeicher
gespeicherteDatenstrukturen
(Flüchtig)
(Nichtflüchtig)
NVM
Peter Sturm
Universität Trier
©PeterSturm,UniversitätTrier
48
Betriebssysteme
Winter2016
Es war einmal …
… sondern:
©PeterSturm,UniversitätTrier
49
Betriebssysteme
Winter2016
• Ganz wenige Kbyte
• Zugriffszeit ~ 300 ps
©PeterSturm,UniversitätTrier
50
Betriebssysteme
Winter2016
• Meist abgestuft (L1, L2, …)
• Meist getrennt (Instruktionen, Daten)
• Beispiel: Xeon Broadwell
• L1 64 Kbyte pro Core, 1 – 2 ns (Hit)
• L2 256 Kbyte pro Core, 3 – 5 ns (Hit)
• L3 6 Mbyte (shared, Server), 10 – 40 ns
UMAs
• “Uniform Memory Architecture”
• Gleiche Speicherzugriffszeit
©PeterSturm,UniversitätTrier
51
Betriebssysteme
Winter2016
Main Memory
• RAM (dynamisch und statisch)
• [ Gbyte … Tbyte ]
• Desktop 8 – 32 GB
• Server – 32 TB (und mehr)
• Zugriffszeit 12-15 ns
Eigenschaften
• Flüchtig
• Inkontinent (Kondensator)
• Verliert Ladung nach
wenigen Millisekunden
• Refresh
©PeterSturm,UniversitätTrier
52
Betriebssysteme
Winter2016
NUMA
Disk / SSD
• Persistenz
• [ Tbyte … viele Tbyte]
• Zugriffszeiten
• Disk 6 – 12 ms und mehr
• SSD ~ 50 us
• IOPs
• Disk 100 – 200
• SSD Mehrere 10k
©PeterSturm,UniversitätTrier
53
Betriebssysteme
Winter2016
GPU
• Small Supercomputer
• Mehrere 1000 Prozessoren
• Komplexe Cache-Struktur
• Bester verfügbarer Speicher
Ethernet
• 1 Gbit/s bis 10 Gbit/s
• Mehrere 10k IOPs
©PeterSturm,UniversitätTrier
54
Betriebssysteme
Winter2016
Verteilte Systeme
Volume
Velocity
Verzögerung
Volatility
Vortune (Vermögen)
©PeterSturm,UniversitätTrier
55
Betriebssysteme
Winter2016
Der “Große Graben”
Wir fordern!!!
Volume
Wenig
Viel
Velocity
Lahm
Schnell
Viel
Wenig
Volatility
Ja
Nein
Vortune
Teuer
Günstig
Verzögerung
©PeterSturm,UniversitätTrier
56
Betriebssysteme
Winter2016
Kernspeicher
©PeterSturm,UniversitätTrier
57
Betriebssysteme
Winter2016
128 Gbyte?
• 1.099.511.627.776 Bits / 256 / 4 cm2
• 1.073.741.824 cm2 = 107.374 m2
• 328m x 328m
RAM / Cache
Volume
Wenig
Viel
Velocity
Lahm
Schnell
Viel
Wenig
Volatility
Ja
Nein
Vortune
Teuer
Günstig
Verzögerung
©PeterSturm,UniversitätTrier
58
Betriebssysteme
Winter2016
Disk
Volume
Wenig
Viel
Velocity
Lahm
Schnell
Viel
Wenig
Volatility
Ja
Nein
Vortune
Teuer
Günstig
Verzögerung
SSD
Volume
Wenig
Velocity
Lahm
Verzögerung
Volatility
Vortune
©PeterSturm,UniversitätTrier
Viel
Schnell
Viel
Wenig
Nein
Ja
Teuer
Günstig
59
Betriebssysteme
Winter2016
Storage Class Memory (SCM)
Volume
Wenig
Velocity
Lahm
Verzögerung
Volatility
Viel
Schnell
Viel
Wenig
Nein
Ja
Teuer
Vortune
Günstig
Fast angekommen!?
Volume
Wenig
Velocity
Lahm
Verzögerung
Wenig
Volatility
Ja
Vortune
Teuer
©PeterSturm,UniversitätTrier
Viel
Viel
Schnell
Wenig Viel
Nein
Teuer
Günstig
60
Betriebssysteme
Winter2016
Indizien
Hard Drive
©PeterSturm,UniversitätTrier
61
Betriebssysteme
©PeterSturm,UniversitätTrier
Winter2016
62
Betriebssysteme
Winter2016
TSV, HBM und HMC
• Through Silicon Via (TSV)
• Aktuell 4 bald 8 Layer
• High Bandwidth Memory (HBM)
• Hybrid Memory Cube (HMC)
• 20 – 40 Gbyte/s Durchsatz
HBM Specs
©PeterSturm,UniversitätTrier
63
Betriebssysteme
Winter2016
3D Chips?
Nvidia Pascal GPU
16 GB HBM2
1 TB/s
17 Milliarden Transistoren
©PeterSturm,UniversitätTrier
64
Betriebssysteme
Winter2016
Details
128 GB DDR4 DIMM
• Samsung, Ende 2015
• TSV Interconnects, 144 DRAM Chips
• 2.4 GT/s * 8 Byte = 19.2 Gbyte/s/DIMM
©PeterSturm,UniversitätTrier
65
Betriebssysteme
Winter2016
Viel Speicher J
128 DIMMs
Bandbreiten
©PeterSturm,UniversitätTrier
66
Betriebssysteme
Winter2016
… Morgen
… Höher
z.B.M.2(PCIe)32Gbit/s
©PeterSturm,UniversitätTrier
67
Betriebssysteme
Winter2016
… ganz hoch
Andere Stimmen
• Geoffrey W. Burr, IBM
• “es fehlt nur noch eine Zehnerpotenz”
ACMQueue,Nov/Dez2015
• Nanavati:
©PeterSturm,UniversitätTrier
68
Betriebssysteme
Winter2016
Memory
CPU
CPU
Memory
©PeterSturm,UniversitätTrier
69
Betriebssysteme
Winter2016
Strukturfolgen
• Komplexität reduzieren
• Weniger Software-Caches
• Geänderte Prioritäten
• CPUs müssen nicht mehr warten
• Weniger Asynchronität
• Mehr Polling ~ ManyCores
Neue Paradigmen
• Neue Datenbankprinzipien
• Jede DB ist In-Memory J
• ”Kriegen wir später”
• Deklarativ
• Knowledge-based
• Machine Learning
©PeterSturm,UniversitätTrier
70
Betriebssysteme
Winter2016
THE END
Peter Sturm
RÜCKBLICK
• Architekturen
• Virtuelle Maschinen
• Synchronisation
• Dateisysteme
(c)PeterSturm,UniversitätTrier
1
Betriebssysteme
Winter2016
ARCHITEKTUR
• Mikrokern vs. Monolith
• Virtuelle Maschinen
• Virtualisierung wird Normalfall
• Software-isolierte Prozesse
• Browser-OS
SYNCHRONISATION: FEIN BIS GROB
• Mikro
• Parallele Schleifen
• Meso
• Futures, Promises, Tasks
• Makro
• Threads
• Anwendungen
(c)PeterSturm,UniversitätTrier
2
Betriebssysteme
Winter2016
TRENDS
• Beschreiben statt Programmieren
• Innovative Ein- und Ausgaben (Gesten, Sprache, ...)
• Mobile Geräte
• Embedded
• Ubiquituous Computing
• Internet of Things
• The Cloud
UBICOMP
(c)PeterSturm,UniversitätTrier
3
Betriebssysteme
Winter2016
Dr. John R. Gold (http://agrilife.org/gold)
Dr. John R. Gold (http://agrilife.org/gold)
(c)PeterSturm,UniversitätTrier
4
Betriebssysteme
Winter2016
ARDUINO UNO
(c)PeterSturm,UniversitätTrier
5
Betriebssysteme
Winter2016
ARDUINO MEGA
GRUSELKABINETT
(c)PeterSturm,UniversitätTrier
6
Betriebssysteme
Winter2016
3.11.2013
(c)PeterSturm,UniversitätTrier
7
Betriebssysteme
Winter2016
http://www.wired.com/design/2012/12/raspberry-pi-roundup/
(c)PeterSturm,UniversitätTrier
8
Betriebssysteme
Winter2016
http://letsmakerobots.com
SUPERCOMPUTER
64 Knoten, Universität Southampton
(c)PeterSturm,UniversitätTrier
9
Betriebssysteme
Winter2016
http://goo.gl/HY5XMx
(c)PeterSturm,UniversitätTrier
10
Betriebssysteme
(c)PeterSturm,UniversitätTrier
Winter2016
11
Betriebssysteme
Winter2016
http://goo.gl/0OzXsz
PEBBLE
(c)PeterSturm,UniversitätTrier
12
Betriebssysteme
Winter2016
HYPE?!
(c)PeterSturm,UniversitätTrier
13
Betriebssysteme
Winter2016
INTEL
(c)PeterSturm,UniversitätTrier
14
Betriebssysteme
Winter2016
UDOO (KICKSTARTER)
(c)PeterSturm,UniversitätTrier
15
Betriebssysteme
Winter2016
PROGRAMMIERUNG
• Verschiedene Lager
• C/C++
• Arduino und Co., Raspberry Pi
• Python, Skratch
• Raspberry Pi
• C# (.NET Micro Framework)
• Netduino
• JavaScript
(c)PeterSturm,UniversitätTrier
16
Betriebssysteme
Winter2016
.NET MICRO FRAMEWORK
• Version 4.3 (Dezember 2012)
• Kleine CLR für C# und VB.NET
• Teilmenge von .NET
• ca. 70 Klassen mit 420 Methoden
• Apache License, Version 2.0
• SDK inkl. Source Code
• Visual Studio Integration
• Debugging
(c)PeterSturm,UniversitätTrier
17
Betriebssysteme
Winter2016
ESPRUINO (KICKSTARTER)
JavaScript
(c)PeterSturm,UniversitätTrier
18
Betriebssysteme
Winter2016
INTERNET DER
DINGE
(c)PeterSturm,UniversitätTrier
19
Betriebssysteme
Winter2016
DEUTLICHES MOMENT
• Hohes Innovationspotential
• Viel Pioniergeist
• Nerds
• Schulen
• Hardware-Hersteller
1% EINSPARUNG (CISCO)
Industrie
Segment
Art
Ersparnis (15J)
Flugverkehr
Kommerziell
-1% Treibstoff
$30 Milliarden
Energie
Gastherme
-1% Gas
$ 66 Milliarden
Gesundheit
Gesamtbereich
-1% Ineffizienz
$63 Milliarden
Schiene
Fracht
-1% Ineffizienz
$27 Milliarden
Öl/Gas
Erschließung
-1% Kosten
$90 Milliarden
http://goo.gl/8QNXIj
(c)PeterSturm,UniversitätTrier
20
Betriebssysteme
Winter2016
DEVICE CLOUDS
REST
IFTTT
(c)PeterSturm,UniversitätTrier
21
Betriebssysteme
Winter2016
ARDUINO YÚN
OpenWRT Linux
TCP/IP Stack
Arduino
(c)PeterSturm,UniversitätTrier
22
Betriebssysteme
Winter2016
NOCH MEHR DATEN
(c)PeterSturm,UniversitätTrier
23
Betriebssysteme
(c)PeterSturm,UniversitätTrier
Winter2016
24