Difference between revisions of "Concurrency with oracles"

From HaskellWiki
Jump to: navigation, search
m (Extra reference added)
m (Minor content changes)
Line 1: Line 1:
  
 
== The problem ==
 
== The problem ==
While there has been research into ''deterministic'' concurrency (e.g. Eleni Spiliopoulou's work with the Bristol Haskell system as described in his thesis [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.60.4364&rep=rep1&type=pdf Concurrent and Distributed Functional Systems]), models of concurrency are generally ''nondeterministic''. For programming languages like Haskell which have the goal of being [[Referential transparency|referentially transparent]], the nondeterminism associated with concurrency presents a challenge - the usual techniques for supporting it used by most other (imperative) languages cannot not be simply transferred verbatim.
+
While there has been research into ''deterministic'' concurrency (e.g. Eleni Spiliopoulou's work with the Bristol Haskell system as described in his thesis [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.60.4364&rep=rep1&type=pdf Concurrent and Distributed Functional Systems]), models of concurrency are generally ''nondeterministic''. For programming languages like Haskell which have the goal of being [[Referential transparency|referentially transparent]], the nondeterminism associated with concurrency presents a challenge - the usual techniques for supporting it used by most other (imperative) languages cannot not be simply transferred verbatim. But neither can nondeterminism be just ignored:
  
But neither can nondeterminism be just ignored - to quote F. Warren Burton from [https://academic.oup.com/comjnl/article-pdf/31/3/243/1157325/310243.pdf Nondeterminism with Referential Transparency in Functional Programming Languages]:
+
<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote">
 +
Nondeterminism is useful in real-time applications where the behaviour of a program should depend on the order in which external events occur. For example, it might be desirable to merge the elements of two lists in the order in which the elements become available. This type of nondeterminism appears to be necessary if functional programs are to be used for real-time computing.
  
<i><blockquote>
+
<tt>[https://academic.oup.com/comjnl/article-pdf/31/3/243/1157325/310243.pdf Nondeterminism with Referential Transparency in Functional Programming Languages], F. Warren Burton.</tt>
Nondeterminism is useful in real-time applications where the behaviour of a program should depend on the order in which external events occur. For example, it might be desirable to merge the elements of two lists in the order in which the elements become available. This type of nondeterminism appears to be necessary if functional programs are to be used for real-time computing.
+
</div>
</blockquote></i>
 
  
 
Other example include:
 
Other example include:

Revision as of 12:40, 10 May 2022

The problem

While there has been research into deterministic concurrency (e.g. Eleni Spiliopoulou's work with the Bristol Haskell system as described in his thesis Concurrent and Distributed Functional Systems), models of concurrency are generally nondeterministic. For programming languages like Haskell which have the goal of being referentially transparent, the nondeterminism associated with concurrency presents a challenge - the usual techniques for supporting it used by most other (imperative) languages cannot not be simply transferred verbatim. But neither can nondeterminism be just ignored:

Nondeterminism is useful in real-time applications where the behaviour of a program should depend on the order in which external events occur. For example, it might be desirable to merge the elements of two lists in the order in which the elements become available. This type of nondeterminism appears to be necessary if functional programs are to be used for real-time computing.

Nondeterminism with Referential Transparency in Functional Programming Languages, F. Warren Burton.

Other example include:

  • which out of two computations will finish first;
  • which input event will arrive first;
  • whether a computation will finish before an input event arrives.

For concurrent programs, nondeterminism is inescapable - events like storage, network or other external failures can occur without warning. The languages used for writing such programs must have some way to allow these programs to cope with such degradation gracefully while continuing to carry out the majority of their designated tasks, albeit at reduced capacity.

How oracles can help

By presenting them to programs via a (theoretically) infinite structured value such as a tree, oracles allow for the controlled use of nondeterminism - wherever the program requires an nondeterministic result, an oracle is then used for this purpose through the use of operations from the interface for the corresponding abstract data type. After it's used, an oracle remains constant - reusing it will not provide a "different" nondeterministic result. Therefore any value determined by an oracle is also constant.

Examples of use

Simon B. Jones and K. V. S. Prasad uses oracles directly for operating and broadcasting systems respectively; Peter Dybjer, Herbert Sander and Mieke Massink use the concept for reasoning about various models of concurrency and their possible applications.

References