Als PDF, PPTX herunterladen
![Erlang/OTP – Ping 1/2
-module(ping).
-export([start/0, ping/1]).
start() ->
spawn(?MODULE, loop, [1]).
ping(Pid) ->
Pid ! {ping, self()},
receive
{pong, _Loop, Count} -> {ok, Count}
after
5000 -> {error, no_pong}
end.](https://image.slidesharecdn.com/2016-oop-spaandernebenlaufigkeit-160209144211/85/Spass-an-der-Nebenlaufigkeit-38-320.jpg)
 do
pinger.ping(_ponger)
end](https://image.slidesharecdn.com/2016-oop-spaandernebenlaufigkeit-160209144211/85/Spass-an-der-Nebenlaufigkeit-61-320.jpg)
Hochgeladen vonFrank Müller
Spaß an der Nebenläufigkeit
Das Dokument behandelt die Konzepte der Nebenläufigkeit in der Softwareentwicklung, insbesondere in Bezug auf moderne Multicore-Systeme und Programmiersprachen wie Erlang, Go und Pony. Es erläutert die Vorteile der Nutzung von nebenläufigen Prozessen und deren Kommunikation, um Ressourcen effizient zu verwalten und Fehler zu minimieren. Zusätzlich werden Herausforderungen wie Rennbedingungen und Blockaden angesprochen, sowie bewährte Methoden zur Vermeidung solcher Probleme.
Spaß an der Nebenläufigkeit
- 1. Spaß an derNebenläufigkeit
- 2. Frank Müller Oldenburg /Deutschland Baujahr 1965 Software-Entwickler Fachautor mue@tideland.biz @themue
- 3. Unsere Welt istnebenläufig
- 4. Naturprinzip • Individuen bevölkerndiese Welt • Sie agieren mal von einander unabhängig, mal abhängig, mal gemeinsam • Kommunikation und Signale ermöglichen ihr Zusammenleben
- 5.
- 6.
- 7.
- 8.
- 9. Menschen bei derArbeit
- 10.
- 11.
- 12. Was bedeutet Nebenläufigkeit in derSoftware?
- 13. Moderne Multicore-Systeme sind wiedie Vereinigung von Flüssen
- 14. Ihre Energie muss effizientgenutzt werden
- 15. Eine Motivation inder Hardware • Rechnerarchitekturen verändern sich • Wachstum über CPUs, Kerne und Hyperthreads • Manuelle Nutzung über Threads komplex und fehlerträchtig • Nebenläufig Laufzeitumgebungen ermöglichen eine feingranulare Nutzung
- 16. Verteilung der Rechenleistung CoreCoreCoreCore Laufzeitumgebung Process Process Process ProcessProcess Process Process Process ProcessProcess
- 17. Nebenläufige Prozesse können ihreeigenen Wege gehen ...
- 18. ... oder auchgemeinsame
- 19. Motivation in derStruktur ist wichtiger • Kapselung des Zustands im Prozess • Kommunikation über Nachrichten • Sequentielle Verarbeitung • Atomare Zustandsänderungen • OOP im eigentlichen Sinne
- 20. ❝ Parallelverarbeitung Programmierung alsgleichzeitige Ausführung möglicherweise zusammen hängender Berechnungen. Nebenläufigkeit Programmierung als Komposition unabhängig ausgeführter Prozesse. –Rob Pike
- 21. Lange bekannte Ideen ActorModel 1973 Carl Hewitt, Peter Bishop und Richard Steiger Communicating Sequential Processes 1978 Tony Hoare
- 22. Actor Model • Aktorensind nebenläufige Prozesse mit einer Adresse oder Kennung • Kommunikation untereinander erfolgt asynchron über einen Nachrichtenversand an die Adresse • Nachrichten werden sequentiell verarbeitet • Prozesszustände sind gekapselt
- 23. Actor Model A CD GFEB E1 E2 E3
- 24. Communicating Sequential Processes •Nebenläufige Prozesse kommunizieren über einen oder mehrere Kanäle • Prozesse sind im Gegensatz zu den Kanälen anonym • Daten werden erst versandt, wenn der Empfänger bereit ist • Eingehende Daten werden sequentiell verarbeitet
- 25. Communicating Sequential Processes A B C D E CFG G H I J K K L M N
- 26. Technologien benötigen ihreZeit • Objektorientierung war lange bekannt • Erste Implementierungen in Simula 67 und Smalltalk-76 • Breite Nutzung erst ab den 90ern durch C++, Java und C# • Nun gewinnen nebenläufige Sprachen an Bedeutung
- 27.
- 28. Prozesse bieten Servicesan Client Client Client Server get_this do_that set_something return this
- 29. Prozesse verwalten zentraleRessourcen Client Client Client Mana- ger A B
- 30. Prozesse dienen derLastverteilung Client Client Worker Worker Worker Master
- 31.
- 32. Prozesse überwachen einander Super- visor Server A Server B' Server B Startetund überwacht A und B Registriert Absturz von B und startet B' neu
- 33. Prozesse sammeln undverteilen Sender Sender Sender In Out Receiver Receiver Receiver
- 34. Prozesse arbeiten vernetzt AC D GFEB E1 E2 E3
- 35.
- 36. Erlang/OTP • 1986 durchEricsson entwickelt • Joe Armstrong, Robert Virding und Mike Williams • Fokus auf Verteilung, Fehlertoleranz, Hochverfügbarkeit, nahezu Echtzeit und Non-Stop-Betrieb • Eigene virtuelle Maschine
- 37. Erlang/OTP • Nebenläufigkeit durchActors • Funktional und dynamisch typisiert • Garbage Collections • Pattern Matching und Guards • Kommunikation über Rechnergrenzen
- 38. Erlang/OTP – Ping1/2 -module(ping). -export([start/0, ping/1]). start() -> spawn(?MODULE, loop, [1]). ping(Pid) -> Pid ! {ping, self()}, receive {pong, _Loop, Count} -> {ok, Count} after 5000 -> {error, no_pong} end.
- 39. Erlang/OTP – Ping2/2 stop(Pid) -> Pid ! stop, ok. loop(Count) -> receive {ping, Sender} -> Sender ! {pong, pid(), Count}, loop(Count + 1); stop -> done end.
- 40. Erlang/OTP - Bedeutungder OTP • Open Telecom Platform • Ursprünglich Fokus auf Telekommunikationsanlagen • 1998 das System AXD301 mit einer Verfügbarkeit von 99,9999999% angekündigt
- 41. Erlang/OTP - Komponentender OTP 1/5 • application • Komponente / Service • Kann eigenständig gestartet und gestoppt werden • Verwaltet Konfiguration für enthaltene Module
- 42. Erlang/OTP - Komponentender OTP 2/5 • supervisor • Startet konfigurierte Prozesse • Kann sie nach Abstürzen erneut starten • Verhalten konfigurierbar • Hierarchien möglich
- 43. Erlang/OTP - Komponentender OTP 3/5 • gen_server • Registrierter oder anonymer Service • Synchrone und asynchrone Requests • Verhalten durch Behaviours bestimmt • Unterstützt Code-Updates im laufenden Betrieb
- 44. Erlang/OTP - Komponentender OTP 4/5 • gen_event • Registrierte oder anonyme Ereignisverarbeitung • Mehrere Behaviours gleichzeitig möglich • Unterstützt Code-Updates im laufenden Betrieb
- 45. Erlang/OTP - Komponentender OTP 5/5 • gen_fsm • Registrierte oder anonyme Zustandsautomaten • Behaviour-Funktionen repräsentieren Zustände • Unterstützt Code-Updates im laufenden Betrieb
- 46. Erlang/OTP – Behaviors1/2 • Generische Module wie gen_server, gen_event und geb_fsm bieten Laufzeitfunktionalität • Behaviour-Module definieren Callbacks mit Geschäftslogik
- 47. Erlang/OTP – Behaviours2/2 -module(my_calc). -behaviour(gen_server). % API. add(A, B) -> gen_server(?MODULE, {add, A, B}, 5000). % Callbacks. handle_call({add, A, B}, _From, State) -> {reply, {ok, A + B}, State}; handle_call({mul, A, B}, _From, State) -> {reply, {ok, A * B}, State}.
- 48. Google Go • 2007durch Google entwickelt • Rob Pike, Ken Thompson und Robert Griesemer • Zielsetzung ist die Systemprogrammierung • Native Binaries
- 49. Google Go • Nebenläufigkeitdurch Goroutinen und Channels • Channels synchron und mit Puffer • Imperative, objektorientierte, und funktionale Aspekte • Garbage Collection
- 50. Google Go –Ping 1/2 type pongChan chan int type pingChan chan pongChan type Ping stuct { pingCh pingChan count int } func New() *Ping { p := &Ping{ pingCh: make(pingChan), count: 0 } go p.loop() return p }
- 51. Google Go –Ping 2/2 func (p*Ping) Ping() int { pongCh := make(pongChan) p.pingCh <- pongCh return <-pongCh } func (p *Ping) loop() { for { select { case pongCh := <-p.pingCh: p.count++ pongCh <- count } } }
- 52. Google Go –Kontrolle von Goroutinen 1/4 • Keine Referenzen auf Goroutinen • Daher kein Monitoring wie in Erlang • Steuerung und Überwachung durch Open-Source-Bibliotheken • github.com/tideland/golib/loop
- 53. Google Go –Kontrolle von Goroutinen 2/4 func (t *MyType) backendLoop(l loop.Loop) error { for { select { case <-l.ShallStop(): return nil case foo := <-t.fooChan: if err := t.processFoo(foo); err != nil { return err } case …: … } } }
- 54. Google Go –Kontrolle von Goroutinen 3/4 // Start der Goroutine in der Startfunktion. t.loop = loop.Go(t.backendLoop) // Dito mit Recover-Funktion. t.loop = loop.GoRecoverable(t.backendLoop, t.recoverLoop) // Schleife beenden. err := t.loop.Stop() // Schleife mit einem Fehler hart beenden und auf Ende warten. t.loop.Kill(myError) err := t.loop.Wait() // Aktuellen Status und eventuellen Fehler abfragen. status, err := t.loop.Error()
- 55. Google Go –Kontrolle von Goroutinen 4/4 // Deadlock im Aufruf vermeiden. func (t *MyType) Foo(foo *Foo) error { select { case t.fooChan <- foo: case <-t.loop.IsStopping(): return errors.New("not running anymore") } return nil }
- 56. Pony • 2015 durchCausality entwickelt • Sylvan Clebsch, Sebastian Blessing, Sophia Drossopoulou, Andrew Mc Neil • Fokus auf Sicherheit, Geschwindigkeit und Einfachheit • LLVM als Laufzeitumgebung
- 57. Pony • Typ- undSpeichersicher • Keine Laufzeitfehler, Exceptions werden immer behandelt • Sicherstellung keiner Data Races • Keine Deadlocks • Garbage Collection
- 58. Pony – Capabilitiesgegen Data Races • Isolated (iso) – verändern, weiterreichen • Value (val) – unveränderlich • Reference (ref) – veränderbar, nicht teilen • Box (box) – sicheres lesen • Transition (trn) – schreiben und anderen Lesezugriff geben • Tag (tag) – nur Identifikation
- 59. Pony – Ping1/3 use "collections" actor Ponger var _env: Env new create(env: Env) => _env = env be pong(count: U64) => _env.out.print(count.string())
- 60. Pony – Ping2/3 actor Pinger var _count: U64 new create() => _count = 0 be ping(ponger: Ponger) => _count = _count + 1 ponger.pong(_count)
- 61. Pony – Ping3/3 actor Main let _ponger : Ponger let _pinger : Pinger new create(env : Env) => _ponger = Ponger(env) _pinger = Pinger for i in Range[U64](0, 5) do pinger.ping(_ponger) end
- 62.
- 63. Volle Message Queuesbzw. Kanäle 1/5 Sender Sender Sender Receiver
- 64. Volle Message Queuesbzw. Kanäle 2/5 • Nicht wie bei OOP überschneidender Zugriff • Serialisierung eingehender Nachrichten • Synchrone Zugriffe werden blockiert, Queues laufen voll und blockieren ebenso
- 65. Volle Message Queuesbzw. Kanäle 3/5 • Last möglichst beim Aufrufer belassen • Zentraler Prozess zur Datenverwaltung • Weitere Last und Daten auf Arbeitsprozesse verteilen • ETS in Erlang und Strukturen mit RWMutex in Go können ebenfalls helfen
- 66. Volle Message Queuesbzw. Kanäle 4/5 Client Server do_this get_data API return data set_data work Client Process
- 67. Volle Message Queuesbzw. Kanäle 5/5 Client B Client A Worker 3 Worker 2 Worker 1 Server do_this do_this return result
- 68.
- 69. Race Conditions 2/4 •Überlagerndes Lesen und Setzen • Update durch Delta mit Rückgabe des neuen Wertes • Alternativ Rückgabe des Wertes mit Handle für Aktualisierung
- 70. Race Conditions 3/4 Client A Client B Server update_amount_by update_amount_by return newamount return new amount
- 71. Race Conditions 4/4 Client A Client B Server get_amount get_amount set_amount_with_handle returnamount and handle return error "no handle"
- 72. Nicht-atomare Veränderungen 1/3 Client A Server Client B set_street set_cityget_street get_city
- 73. Nicht-atomare Veränderungen 2/3 •Auslöser sind zu granuläre Nachrichten und nicht eingehaltene Protokolle • Zusammenhängende Daten gleichzeitig ändern beziehungsweise auslesen
- 74.
- 75. Blockaden durch Cycles1/3 Process A Process B Process C get_foo get_bar get_yadda return return
- 76. Blockaden durch Cycles2/3 • Auslöser sind synchrone Abfragen • Timeouts zeigen Blockaden auf, vermeiden jedoch nicht den Fehler • Design auf Basis asynchroner Kommunikation • Zustandsänderungen in den Prozessen müssen dies berücksichtigen
- 77. Blockaden durch Cycles3/3 Process A Process B Process C get_foo 1 get_bar 1 get_yadda 1 set_bar 1 set_foo 1 set_yadda 1
- 78.
- 79. Belohnung • Natürliche Strukturenin der Software • Elastisches Verhalten • Problemlose Skalierung mit der Hardware • Hohe Sicherheit im Laufzeitverhalten
- 80.