HTWG: Events, Send & Sync

Gastvorlesung an der HTWG Konstanz zu Rust Futures

1. Events, Send und Sync
2. Wie können wir unzusammenhängende Berechnungen effizient für den Computer abbilden?
3. Option 1: Threads r Berechnungen werden nebenläufig ausgeführt r Ein Scheduler verwaltet die Ausführung r Haben einen eigenen Stack r Teilen den Heap r Können einzeln blockieren
4. Vorteile r Folgen im Einzelnen einem (relativ) linearen Modell r Auf (fast) allen Betriebssystem nativ unterstützt r Threads haben einen eigenen Spe- icherbereich (thread-local storage) r Stacks können zum debuggen be- nutzt werden
5. Nachteile r Jeder Thread braucht Platz für einen Stack r Es können recht einfach Synchro- nisierungsbugs auftreten
6. Populäre Threaded-Systeme r Apache r Varnish r Apache Tomcat
7. r Jede Aktion ist ein "Event" r Das System hält eine Liste zu bear- beitender Events r Eine große Schleife arbeitet diese Events nach und nach ab r Events können weitere Events auslösen r Aktionen haben keine Verbindung über den Stack
8. Vorteile r Eine Aktion zu einer Zeit: weniger Synchronisierungsprobleme r Blockaden werden durch Einreihen ans Ende der Queue abgebildet r Blockaden sind sehr günstig
9. Nachteile r Aktionen, die den ausführenden Thread doch blockieren, blockieren alles r Schwer zu folgen, da Reihenfolge selbst herzustellen ist
10. Populäre Evented-Systeme r Java NIO ("new I/O") r V8/node.js r nginx r BEAM (Erlang-VM)
11. Option 3: Beides Viel Spass!
12. Populäre Systeme mit beidem r Datenbanken, z.B. Elasticsearch r Spiele r Fast jede moderne Desktop-App
13. Mehr Sicherheit? Können wir Abstraktionen finden, die uns hier hilft?
14. Unabhängig von beiden Ansätzen?
15. Send und Sync
16. Send Ein Wert kann zwischen Threads abgegeben werden. Der sendende Thread verliert den Zugriff. Der Zugriff bleibt exklusiv.
17. Der Compiler stellt "Send" automatisch fest, wenn alle inneren Werte Send sind.
18. Insbesondere nicht Send sind alle Werte, die geteilte, mutable Daten enthalten.
19. Sync Ein Wert kann zwischen Threads geteilt werden. Der sendende Thread behält den Zugriff. Der Zugriff wird geteilt.
20. Der Compiler stellt "Sync" automatisch fest, wenn alle inneren Werte Sync sind.
21. Send und Sync sind elegant Sie sagen nichts spezifisches über die verwendete Technologie aus. Sie erlauben aber spezifisches Arbeiten mit einer Technologie.
22. Send und Sync abstrahieren über Daten. Was fehlt?
23. Semantisches Problem Rust ist synchron und imperativ: Aktionen finden nacheinander statt und können nicht pausiert werden.
24. Nebenläufige Programme sind: r Unvorhersagbar r Reaktiv r Zeitorientiert
25. Result enum Result<T, E> { Ok(T), Err(E) }
26. Futures trait Future { type Item; type Error; fn poll(&mut self) -> Result<Async<T>, E>; fn wait(self) -> Result<T, E>; }
27. Async r Ok(Async::Ready(t)) -> Die Future ist fertig r Ok(Async::NotReady) -> Die Future arbeitet noch r Err(e) -> Ein Fehler ist aufgetreten
28. Futures Futures abstrahieren eine Berechnung, die in der Zukunft beendet sein könnte und entweder erfolgreich oder zu einem Fehler führen wird.
29. Sozusagen: ein Result in der Zukunft.
30. Futures gibt es auch unter dem Namen "Promises".
32. Lingo r Eine Future ist "aufgelöst", wenn das Ergebnis da ist. r "deferred computation" r Futures am Ende einer Berechnung heissen "Blätter"
33. fn main() { let timer = Timer::default(); let sleep = timer.sleep(Duration::from_millis(1000)) .inspect("sleep"); let cpu_pool = CpuPool::new(4); let task = cpu_pool.spawn(sleep); println!("{:?}", task.wait()); }
34. Future sleep polled: Ok(NotReady) Future sleep polled: Ok(Ready(())) Ok(())
35. Exekutoren Exekutoren sind die Implementierung der Ausführungsstrategie von Futures.
36. futures-cpupool Mehrere Threads führen Futures parallel aus. Die Ausführung findet stets parallel statt.
37. tokio-core tokio-core hält eine Liste ausführbarer Futures und arbeitet diese eine nach dem anderen ab. Futures, die gerade nicht ausführbar sind, werden zurück in die Liste gebracht.
38. use tokio_core::reactor::Core; fn main() { let timer = Timer::default(); let sleep = timer.sleep(Duration::from_millis(1000)) .inspect("sleep"); let mut core = Core::new().unwrap(); let task = core.run(sleep); println!("{:?}", task); }
39. Future sleep polled: Ok(NotReady) Future sleep polled: Ok(Ready(())) Ok(())
40. Protokoll r Futures werden beim ersten poll() gestartet r Sie können beliebig oft "NotReady" antworten r Ein weiterer Aufruf von poll() nach "Ready" ist nicht erlaubt
41. Kombination von Futures fn main() { let timer = Timer::default(); let sleep = timer.sleep(Duration::from_millis(1000)) .inspect("sleep") .and_then(|_| { timer.sleep(Duration::from_millis(500)) .inspect("sleep some more") }); let mut core = Core::new().unwrap(); let task = core.run(sleep); println!("{:?}", task); }
42. Future sleep polled: Ok(NotReady) Future sleep polled: Ok(Ready(())) Future sleep some more polled: Ok(NotReady) Future sleep some more polled: Ok(Ready(())) Ok(())
43. Futures beschreiben Abhängigkeiten zwischen zukünftigen Berechnungen.
44. Result "Wenn jetzt X eintrat, dann..."
45. Future "Wenn in Zukunft X eintritt, dann..."
46. Kombinatoren: join_all join_all fügt mehrere Futures zu einer neuen Future zusammen, die aufgelöst wird, wenn alle Blätter aufgelöst werden.
47. fn main() { let timer = Timer::default(); let sleep = timer.sleep(Duration::from_millis(1500)) .inspect("sleep"); let sleep_shorter = timer.sleep(Duration::from_millis(500)) .inspect("short sleep"); let join = join_all(vec![sleep, sleep_shorter]) .inspect("join"); let mut core = Core::new().unwrap(); let result = core.run(join); println!("{:?}", result); }
48. Future sleep polled: Ok(NotReady) Future short sleep polled: Ok(NotReady) Future join polled: Ok(NotReady) Future sleep polled: Ok(NotReady) Future short sleep polled: Ok(Ready(())) Future join polled: Ok(NotReady) Future sleep polled: Ok(Ready(())) Future join polled: Ok(Ready([(), ()])) Ok([(), ()])
49. Kombinatoren: select_all select_all fügt mehrere Futures zu einer neuen Future zusammen, die aufgelöst wird, wenn das erste Kind aufgelöst werden.
50. fn main() { let timer = Timer::default(); let sleep = timer.sleep(Duration::from_millis(1000)) .inspect("sleep"); let short_sleep = timer.sleep(Duration::from_millis(500)) .inspect("short sleep");
51. let select = select_all(vec![sleep, short_sleep]) .inspect("first select"); let mut core = Core::new().unwrap(); let (result, index, remaining_futures) = core.run(select).un println!("Future with index {} returned {:?}", index, result); let select = select_all(remaining_futures) .inspect("second select"); let (result, index, _) = core.run(select).unwrap(); println!("Future with index {} returned {:?}", index, result); }
52. Future sleep polled: Ok(NotReady) Future short sleep polled: Ok(NotReady) Future first select polled: Ok(NotReady) Future sleep polled: Ok(NotReady) Future short sleep polled: Ok(Ready(())) Future first select polled: Ok(Ready(((), 1, [ InspectFuture { future: Sleep { timer: Timer Future with index 1 returned () Future sleep polled: Ok(NotReady) Future second select polled: Ok(NotReady) Future sleep polled: Ok(Ready(())) Future second select polled: Ok(Ready(((), 0, [] Future with index 0 returned ()
53. Eine Umformung let select = select_all(vec![sleep, short_sleep]) .inspect("select_all") .and_then(|(result, index, futures)| { println!("Future with index {} returned {:?}", index, result); select_all(futures) .inspect("nested select_all") }); let mut core = Core::new().unwrap(); let (result, index, _) = core.run(select).unwrap(); println!("Future with index {} returned {:?}", index, result);
54. Future sleep polled: Ok(NotReady) Future short sleep polled: Ok(NotReady) Future select_all polled: Ok(NotReady) Future sleep polled: Ok(NotReady) Future short sleep polled: Ok(Ready(())) Future select_all polled: Ok(Ready(((), 1, [ InspectFuture { future: Sleep { timer: Timer Future with index 1 returned () Future sleep polled: Ok(NotReady) Future nested select_all polled: Ok(NotReady) Future sleep polled: Ok(Ready(())) Future nested select_all polled: Ok(Ready(((), 0 Future with index 0 returned ()
55. Jetzt! Futures können auch sofortige Berechnung darstellen. Hierzu können wir von Results zu einer Future übergehen.
56. let file = File::open("absent"); let future = futures::result(file);
57. Wird diese Future gepollt, ist sie sofort fertig.
58. Fazit Futures sind ein kombinierbares Konzept zur Nebenläufigkeitsberechnung, das keine konkrete Ausführungstechnik vorgibt.
59. Futures sind momentan DAS beherrschende Konzept zur Nebenläufigkeitsabstraktion.
60. Beispiele r Java Futures r Promises/A in der JavaScript-Welt
61. Tokio Futures werden selten so roh wie hier verwendet. Als Beispiel kann das Tokio-Framework dienen. https://tokio.rs/
63. Tokio r Ein Event-Framework (Reactor) r Eine Sammlung von Komponenten zur Server-Entwicklung
64. Tokio stellt teilweise Synchronität wieder her.
65. Halb-synchron: Tokio-Service pub trait Service { /// Requests handled by the service. type Request; /// Responses given by the service. type Response; /// Errors produced by the service. type Error; /// The future response value. type Future: Future<Item = Self::Response, Error = Self::Error>; /// Process the request and return the response asynchronous fn call(&self, req: Self::Request) -> Self::Future; }
66. r Nimmt synchron eine Anfrage an r Gibt einen Wert zurück, der eine zukünftige Antwort anzeigt r Das asynchrone Aufrufen des Ser- vices übernimmt Tokio
67. impl Service for MailboxService<String> { type Request = redisish::Command; type Response = ServerResponse; type Error = io::Error; type Future = FutureResult<Self::Response, Self::Error>; fn call(&self, command: Self::Request) -> Self::Future { /// .... } }
68. Tokio abstrahiert darüber über asynchronen Input/Output.
69. https://tokio.rs/docs/getting- started/simple-server/
70. Futures und das darauf aufbauende Tokio bieten eine mächtige Abstraktion über asynchrone Systeme.