From 811308d8e24e1be226cd5e8ce1159fe3802b66c3 Mon Sep 17 00:00:00 2001 From: gshen42 Date: Tue, 16 Apr 2024 16:31:53 +0000 Subject: [PATCH] regenerate after: update Dan's talk --- index.xml | 16 ++++++++++++++-- lsd-seminar/2024sp/index.html | 16 ++++++++++++++-- themes/academic | 1 + 3 files changed, 29 insertions(+), 4 deletions(-) create mode 160000 themes/academic diff --git a/index.xml b/index.xml index 94a8437..08e9e99 100644 --- a/index.xml +++ b/index.xml @@ -46,9 +46,9 @@ </tr> <tr> -<td>April 12</td> +<td><a href="#april-12">April 12</a></td> <td>Dan Plyukhin</td> -<td><em>TBD</em></td> +<td>Ozone: Fully Out-of-Order Choreographies</td> </tr> <tr> @@ -125,6 +125,18 @@ <p>He is based in the compiler teams at Arm in Cambridge where he assists engineers with finding bugs and deploying automated concurrency testing as part of an EPSRC grant. Luke&rsquo;s opinions are his own and Arm does not endorse his work.</p> +<h2 id="april-12">April 12</h2> + +<p><strong>Speaker:</strong> Dan Plyukhin</p> + +<p><strong>Title:</strong> Ozone: Fully Out-of-Order Choreographies</p> + +<p><strong>Abstract:</strong> Choreographic programming is a paradigm for writing distributed applications. It allows programmers to write a single program, called a choreography, that can be compiled to generate correct implementations of each process in the application. Although choreographies provide good static guarantees, they can exhibit high latency when messages or processes are delayed. This is because processes in a choreography typically execute in a fixed, deterministic order, and cannot adapt to the order that messages arrive at runtime. In non-choreographic code, programmers can address this problem by allowing processes to execute out of order &ndash; for instance by using futures or reactive programming. However, in choreographic code, out-of-order process execution can lead to serious and subtle bugs, called communication integrity violations (CIVs).</p> + +<p>In this paper, we develop a model of choreographic programming for out-of-order processes that guarantees absence of CIVs and deadlocks. As an application of our approach, we also introduce an API for safe non-blocking communication via futures in the choreographic programming language Choral. The API allows processes to execute out of order, participate in multiple choreographies concurrently, and to handle unordered or dropped messages as in the UDP transport protocol. We provide an illustrative evaluation of our API, showing that out-of-order execution can reduce latency by overlapping communication with computation.</p> + +<p><strong>Bio:</strong> Dan works as a postdoc at the University of Southern Denmark and is receiving his PhD from the University of Illinois at Urbana-Champaign (UIUC). He is the author of the UIGC library for Akka, which provides fault-tolerant resource management for distributed actor systems. Dan’s research focuses on making distributed reactive applications easier to write and reason about.</p> + <hr /> <p><a href="../">Archive</a></p> diff --git a/lsd-seminar/2024sp/index.html b/lsd-seminar/2024sp/index.html index ff779bf..cf51dd0 100644 --- a/lsd-seminar/2024sp/index.html +++ b/lsd-seminar/2024sp/index.html @@ -227,9 +227,9 @@

Languages, Systems, and Data Seminar (Spring 2024)

-April 12 +April 12 Dan Plyukhin -TBD +Ozone: Fully Out-of-Order Choreographies @@ -306,6 +306,18 @@

April 5

He is based in the compiler teams at Arm in Cambridge where he assists engineers with finding bugs and deploying automated concurrency testing as part of an EPSRC grant. Luke’s opinions are his own and Arm does not endorse his work.

+

April 12

+ +

Speaker: Dan Plyukhin

+ +

Title: Ozone: Fully Out-of-Order Choreographies

+ +

Abstract: Choreographic programming is a paradigm for writing distributed applications. It allows programmers to write a single program, called a choreography, that can be compiled to generate correct implementations of each process in the application. Although choreographies provide good static guarantees, they can exhibit high latency when messages or processes are delayed. This is because processes in a choreography typically execute in a fixed, deterministic order, and cannot adapt to the order that messages arrive at runtime. In non-choreographic code, programmers can address this problem by allowing processes to execute out of order – for instance by using futures or reactive programming. However, in choreographic code, out-of-order process execution can lead to serious and subtle bugs, called communication integrity violations (CIVs).

+ +

In this paper, we develop a model of choreographic programming for out-of-order processes that guarantees absence of CIVs and deadlocks. As an application of our approach, we also introduce an API for safe non-blocking communication via futures in the choreographic programming language Choral. The API allows processes to execute out of order, participate in multiple choreographies concurrently, and to handle unordered or dropped messages as in the UDP transport protocol. We provide an illustrative evaluation of our API, showing that out-of-order execution can reduce latency by overlapping communication with computation.

+ +

Bio: Dan works as a postdoc at the University of Southern Denmark and is receiving his PhD from the University of Illinois at Urbana-Champaign (UIUC). He is the author of the UIGC library for Akka, which provides fault-tolerant resource management for distributed actor systems. Dan’s research focuses on making distributed reactive applications easier to write and reason about.

+

Archive

diff --git a/themes/academic b/themes/academic new file mode 160000 index 0000000..8d596ff --- /dev/null +++ b/themes/academic @@ -0,0 +1 @@ +Subproject commit 8d596ffed2d080010c561679cf4e9b4da1554781