12.07.2015 Views

Technical Report - Microsoft Research

Technical Report - Microsoft Research

Technical Report - Microsoft Research

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

specific approaches such as Nooks [49]; and provides simple semantic guarantees that can beunderstood by programmers and used by tools.The principal arguments against Singularity’s extension model center on the difficulty ofwriting message-passing code. We hope that better programming models and languages willmake programs of this type easier to write, verify, and modify. Advances in this area would begenerally beneficial, since message-passing communication is fundamental and unavoidable indistributed computing and web services. As message passing becomes increasingly familiar andtechniques improve, objections to programming this way within a system are likely to becomeless common.Finally, Singularity does not use memory management hardware on processors forprotection, which suggests the possibility of reevaluating this hardware. In general, manyprograms only use some of the functionality of memory management hardware. Embeddedsystems (or adequately provisioned workstations and servers) rarely page because memory isinexpensive and abundant. Large (64-bit) address spaces reduce the need to use multiple addressspaces to get around 32-bit limitations. And, Singularity shows how safe languages andconservative sharing policies can supplant process boundaries and protection rings, at lower cost.Current hardware, if not fully utilized, might be replaced by simpler mechanisms with fewerperformance bottlenecks such as TLBs.Singularity would benefit from memory protection for its trusted (unverified) base. Forexample, DMA currently is inherently unsafe and, because of different interfaces on each device,cannot be encapsulated or virtualized by a system. Memory protection for DMA transfers couldprotect the system against a misdirected DMA. Hardware support for segmented stacks couldreduce the compiler complexity and run-time overhead of this mechanism.4 Programming Language SupportSingularity is written in Sing#, which is an extension to the Spec# language developed in<strong>Microsoft</strong> <strong>Research</strong>. Spec# itself is an extension to <strong>Microsoft</strong>’s C# language that providesconstructs (pre- and post-conditions and object invariants) for specifying program behavior [7].Specifications can be statically verified by the Boogie verifier or checked by compiler-insertedrun-time tests. Sing# extends this language with support for channels and low-level constructsnecessary for system code.We developed and implemented programming language extensions for two reasons. First,few languages support message-passing communication. In most cases, message passing isrelegated to libraries, which are a syntactically and semantically awkward way of graftingasynchronous operations onto a synchronous language such as C#. Sing# provides first-classsupport for message-passing communications, which makes this style of communication, and theSIP abstractions, more efficient to implement and more palatable to programmers. Second,integrating a feature into a language allows more aspects of a program to be verified.Singularity’s constructs allow communication to be statically verified.4.1 Channel ContractsChannel contracts are central to Singularity’s isolation architecture and are directlysupported in Sing#. Here’s a contract describing a simple interaction on a channel.14

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!