Commit 52458383 authored by Jacques-Henri Jourdan's avatar Jacques-Henri Jourdan
Browse files

stream -> sequence

parent 8e6d31f0
......@@ -5,12 +5,12 @@
The code of the application is presented in~\fref{fig:pipeline:impl}.
It provides a single function, \pipeline, which takes as arguments two
functions~$g$ and~$f$, a stream~$\refXArray$, and returns a stream
obtained by applying $g \circ f$ to each item of the input stream.
functions~$g$ and~$f$, a sequence~$\refXArray$, and returns a sequence
obtained by applying $g \circ f$ to each item of the input sequence.
The functions~$g$ and~$f$ need not be pure: they can have side effects and rely
on some state.
For simplicity, input and output streams are encoded as (nonatomic) arrays,
For simplicity, input and output sequences are encoded as (nonatomic) arrays,
whose length can be obtained via a primitive operation $\Length -$.
However the implementation can be modified to consume and produce lists of
unknown length, or even infinite streams, provided an encoding of such
......@@ -25,5 +25,5 @@ The forked thread reads items from~\refXArray in turn, applies $f$ to them
and enqueues the results.
The main thread creates a new (nonatomic) array~\refZArray to store the output;
then, it dequeues $\nbelems$~items, where $\nbelems$ is the number of items in
the input stream, applies $g$ to them, and adds the results to \refZArray.
the input sequence, applies $g$ to them, and adds the results to \refZArray.
Finally, it returns~\refZArray.
......@@ -10,5 +10,5 @@ More precisely, $\pipelineInv R$ join together the queue invariant $\queueInv$ w
In addition, $\pipelineF R \curf \refXArray \xElemList$ and $\pipelineG R \curg \refZArray \zElemList$ are loop invariants used in the two computing threads.
The pipeline invariant uses the ghost variables $\gcurf$ and $\gcurg$ to agree with the loop invariants on their position, and, in addition to owning the exclusive ownership of the queue, states that each element of the queue is associated with a weakest precondition assertion at the element's view allowing to execute the function $g$ on this element.
Once the invariants are stated and initialized, the proof is a straightforward induction over the length of the input stream: at each step of each thread, we execute either $f$ or $g$, we open the global pipeline invariant around the logically atomic triple of the enqueing or dequeueing operation.
Once the invariants are stated and initialized, the proof is a straightforward induction over the length of the input sequence: at each step of each thread, we execute either $f$ or $g$, we open the global pipeline invariant around the logically atomic triple of the enqueing or dequeueing operation.
When this invariant is opened, the state of the queue can be updated, and we perform an update on the ghost variables $\gcurf$ or $\gcurg$ to reflect the state change in the corresponding thread.
\section{A Simple Pipeline}
\label{sec:pipeline}
% TODO JH : stream -> sequence
We now demonstrate the use of our specification in Cosmo of a concurrent queue
library with a simple client application, that chains two treatments on a stream
library with a simple client application, that chains two treatments on a sequence
of data, where each treatment is applied by a separate thread. Thus the
stream of intermediate values is transferred from a producer to a consumer
sequence of intermediate values is transferred from a producer to a consumer
using a concurrent queue.
% GLEN: "stream" est un peu prétentieux, c’est un tableau de taille connue…
\input{pipeline-impl}
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment