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 | 34 | |
| 35 | 35 | However, the \texttt{maybe} statement represents a fundamentally different |
| 36 | 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 | 82 | rewrite-based prototype, described next in Section~\ref{sec-certainty}, we |
| 83 | 83 | will revisit the question of nesting in future compiler-driven \texttt{maybe} |
| 84 | 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 | 2 | @string{sosp = "SOSP"} |
| 3 | 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 | 43 | @inproceedings{gomez2013reran, |
| 6 | 44 | title={Reran: Timing-and touch-sensitive record and replay for android}, |
| 7 | 45 | author={Gomez, Lorenzo and Neamtiu, Iulian and Azim, Tanzirul and Millstein, Todd}, | ... | ... |
related.tex
| 1 | 1 | \section{Related Work} |
| 2 | 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 | 13 | Aspect oriented programming (AOP)~\cite{aop} was proposed by Kiczales et al. |
| 5 | 14 | as a programming paradigm geared toward increasing modularity through the |
| 6 | 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 | 28 | use of a JIT. Fundamentally, however, the goals of AOP and the \texttt{maybe} |
| 20 | 29 | statement differ, with AOP focusing on modularity and \texttt{maybe} focused |
| 21 | 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. | ... | ... |