Commit 390e2adcd9c02e54dc3ddecd88555dc18bced569
1 parent
e9c9a29b
New.
Showing
4 changed files
with
86 additions
and
5 deletions
discussion.tex
| @@ -34,9 +34,19 @@ is reduced. | @@ -34,9 +34,19 @@ is reduced. | ||
| 34 | 34 | ||
| 35 | However, the \texttt{maybe} statement represents a fundamentally different | 35 | However, the \texttt{maybe} statement represents a fundamentally different |
| 36 | approach from previously attempts to enable runtime adaptation that relied on | 36 | approach from previously attempts to enable runtime adaptation that relied on |
| 37 | -libraries. First, libraries | 37 | +libraries. As a code organization stategy, the benefits that libraries provide |
| 38 | +in terms of reduced duplication and more powerful interfaces are orthogonal and | ||
| 39 | +complementary to the \texttt{maybe} statement. That said, a large amount of | ||
| 40 | +code including adaptation logic remains app specific and cannot be refactored | ||
| 41 | +into a library. | ||
| 38 | 42 | ||
| 39 | -Finally, note that structured uncertainty is not randomness. The | ||
| 40 | -\texttt{maybe} statement indicates that during any given execution one | ||
| 41 | -alternative may be better than the others---even if the developer or system | ||
| 42 | -are not sure which alternative to use. | 43 | +More importantly, library development still requires development-time |
| 44 | +certainty. Despite the fact that library developers are more likely to be | ||
| 45 | +experts at the type of adaptation the library performs, we still believe that | ||
| 46 | +even the most skilled programmers are not capable of anticipating all | ||
| 47 | +possible sources of uncertainty and will benefit from being able to express | ||
| 48 | +structured uncertainty. \texttt{maybe} allows all developers---including both | ||
| 49 | +app and library writers---to shed the burden of producing a single certain | ||
| 50 | +approach and instead write uncertain code containing the flexibility needed | ||
| 51 | +required to enable powerful data-driven approaches to post-deployment | ||
| 52 | +adaptation. |
maybe.tex
| @@ -82,3 +82,9 @@ maintained across multiple code blocks. As we gain more experience with our | @@ -82,3 +82,9 @@ maintained across multiple code blocks. As we gain more experience with our | ||
| 82 | rewrite-based prototype, described next in Section~\ref{sec-certainty}, we | 82 | rewrite-based prototype, described next in Section~\ref{sec-certainty}, we |
| 83 | will revisit the question of nesting in future compiler-driven \texttt{maybe} | 83 | will revisit the question of nesting in future compiler-driven \texttt{maybe} |
| 84 | systems. | 84 | systems. |
| 85 | + | ||
| 86 | +As a final remark, note that structured uncertainty is not randomness. | ||
| 87 | +Randomness weights multiple options statically---there is no right or wrong | ||
| 88 | +choice. In contrast, the \texttt{maybe} statement indicates that during any | ||
| 89 | +given execution one alternative may be the right choice---even if the | ||
| 90 | +developer or system cannot yet identify it. |
references.bib
| @@ -2,6 +2,44 @@ | @@ -2,6 +2,44 @@ | ||
| 2 | @string{sosp = "SOSP"} | 2 | @string{sosp = "SOSP"} |
| 3 | @string{osdi = "OSDI"} | 3 | @string{osdi = "OSDI"} |
| 4 | 4 | ||
| 5 | +@article{badrinath2000conceptual, | ||
| 6 | + title={A conceptual framework for network and client adaptation}, | ||
| 7 | + author={Badrinath, B and Fox, Armando and Kleinrock, Leonard and Popek, Gerald and Reiher, Peter and Satyanarayanan, Mahadev}, | ||
| 8 | + journal={Mobile Networks and Applications}, | ||
| 9 | + volume={5}, | ||
| 10 | + number={4}, | ||
| 11 | + pages={221--231}, | ||
| 12 | + year={2000}, | ||
| 13 | + publisher={Springer-Verlag New York, Inc.} | ||
| 14 | +} | ||
| 15 | + | ||
| 16 | +@inproceedings{odyssey-sosp97, | ||
| 17 | + Address = {Saint Malo, France}, | ||
| 18 | + Author = {Brian D. Noble and M. Satyanarayanan and Dushyanth Narayanan and James Eric Tilton and Jason Flinn and Kevin R. Walker}, | ||
| 19 | + Booktitle = {SOSP '97: Proceedings of the sixteenth ACM symposium on Operating systems principles}, | ||
| 20 | + Pages = {276--287}, | ||
| 21 | + Title = {Agile application-aware adaptation for mobility}, | ||
| 22 | + Year = {1997}} | ||
| 23 | + | ||
| 24 | +@article{arxiv13-enframe, | ||
| 25 | + title={ENFrame: A Platform for Processing Probabilistic Data}, | ||
| 26 | + author={van Schaik, Sebastiaan J and Olteanu, Dan and Fink, Robert}, | ||
| 27 | + journal={arXiv preprint arXiv:1309.0373}, | ||
| 28 | + year={2013} | ||
| 29 | +} | ||
| 30 | + | ||
| 31 | +@inproceedings{sensys07-eon, | ||
| 32 | + title={{Eon: A Language and Runtime System for Perpetual Systems}}, | ||
| 33 | + author="J Sorber and A Kostadinov and M Brennan and M Garber and M Corner and E D Berger", | ||
| 34 | + booktitle="ACM Conference on Embedded Networked Sensor Systems (SenSys'07)", | ||
| 35 | + month="November", year="2007"} | ||
| 36 | + | ||
| 37 | +@inproceedings{sensys07-levels, | ||
| 38 | + title={{Meeting lifetime goals with energy levels}}, | ||
| 39 | + author="A Lachenmann and P J Marron and D Minder and K Rothermer", | ||
| 40 | + booktitle="ACM Conference on Embedded Networked Sensor Systems (SenSys'07)", | ||
| 41 | + month="November", year="2007"} | ||
| 42 | + | ||
| 5 | @inproceedings{gomez2013reran, | 43 | @inproceedings{gomez2013reran, |
| 6 | title={Reran: Timing-and touch-sensitive record and replay for android}, | 44 | title={Reran: Timing-and touch-sensitive record and replay for android}, |
| 7 | author={Gomez, Lorenzo and Neamtiu, Iulian and Azim, Tanzirul and Millstein, Todd}, | 45 | author={Gomez, Lorenzo and Neamtiu, Iulian and Azim, Tanzirul and Millstein, Todd}, |
related.tex
| 1 | \section{Related Work} | 1 | \section{Related Work} |
| 2 | \label{sec-related} | 2 | \label{sec-related} |
| 3 | 3 | ||
| 4 | +New systems such as EnFrame~\cite{arxiv13-enframe} reflect growing interest | ||
| 5 | +in managing uncertainty at the language level. EnFrame focuses on enabling | ||
| 6 | +programming with uncertain data, rather than the runtime adaptation enabled | ||
| 7 | +by the \texttt{maybe} statement. Specifically a variable controlled by a | ||
| 8 | +\texttt{maybe} statement has a single value that is being evaluated at any | ||
| 9 | +given time, while EnFrame allows that same variable to have a distribution of | ||
| 10 | +values reflecting error or other forms of uncertainty about what it's true | ||
| 11 | +value should be. | ||
| 12 | + | ||
| 4 | Aspect oriented programming (AOP)~\cite{aop} was proposed by Kiczales et al. | 13 | Aspect oriented programming (AOP)~\cite{aop} was proposed by Kiczales et al. |
| 5 | as a programming paradigm geared toward increasing modularity through the | 14 | as a programming paradigm geared toward increasing modularity through the |
| 6 | separation of cross-cutting concerns in software. The programmer can express | 15 | separation of cross-cutting concerns in software. The programmer can express |
| @@ -19,3 +28,21 @@ Unfortunately, dynamic weaving and unweaving can be expensive, requiring the | @@ -19,3 +28,21 @@ Unfortunately, dynamic weaving and unweaving can be expensive, requiring the | ||
| 19 | use of a JIT. Fundamentally, however, the goals of AOP and the \texttt{maybe} | 28 | use of a JIT. Fundamentally, however, the goals of AOP and the \texttt{maybe} |
| 20 | statement differ, with AOP focusing on modularity and \texttt{maybe} focused | 29 | statement differ, with AOP focusing on modularity and \texttt{maybe} focused |
| 21 | on increasing runtime flexibility in the face of uncertainty. | 30 | on increasing runtime flexibility in the face of uncertainty. |
| 31 | + | ||
| 32 | +\texttt{maybe} shares similaries with language-based approaches to managing | ||
| 33 | +energy consumption in wireless sensor networks such as | ||
| 34 | +Eon~\cite{sensys07-eon} and Levels~\cite{sensys07-levels}. However, these | ||
| 35 | +approaches still require programmers to express certainty by associating code | ||
| 36 | +with particular energy states, rather than allowing the runtime system to | ||
| 37 | +determine which energy states are appropriate as the \texttt{maybe} system | ||
| 38 | +would be able to do. \texttt{maybe} can also enable adaptation driven by | ||
| 39 | +goals other than energy management. | ||
| 40 | + | ||
| 41 | +Enabling more adaptive mobile systems is a challenge with a long history dating | ||
| 42 | +back to work on systems such as Odyssey~\cite{odyssey-sosp97}. However, a | ||
| 43 | +taxonomy of approaches to enabling adaptation on early mobile | ||
| 44 | +systems~\cite{badrinath2000conceptual} reflects the focus of early efforts on | ||
| 45 | +incorporating adaptation into libraries that could be used by multiple apps. As | ||
| 46 | +we have pointed out previously, while adaptation libraries are useful, | ||
| 47 | +\texttt{maybe} statements can make them more powerful by allowing programmers | ||
| 48 | +to express uncertainty. |