The Physics of Software

CS444a – Principles of Dependable Computer Systems

Stanford University

November 18, 2003

Overview

„ Building
z in the physical world
z in the software world

„ Potential “laws of physics” for software:

1. Output Law
2. Input Law
3. Failure Law
4. Consumption Law

z Turning laws into design

2 © 2003 George Candea

Building in the Physical World
“Snap back to reality
Oh there goes gravity”
(Eminem, 8 Mile Soundtrack)

„ mature engineering disciplines deal with physical embodiment

z physics: have macroscopic descriptive laws

„ laws of physics capture in simple form an observed physical invariant

z Newton’s 2nd Law of Motion: F=ma
z Ohm’s Law: V = I x R
z Snell’s Law (reflection and refraction): n1·sinΘ1 = n2·sinΘ2

„ can develop a science for

z assembling systems
z understanding and predicting their behavior

„ prototypes (failures + successes) Æ learn how to apply laws

z redundancy to survive some failures
z margin of safety (e.g., 3 x expected load)

3 © 2003 George Candea

Examples

„ Railroad bridges

„ Robots

„ Lasers

4 © 2003 George Candea

Building Software “Snap back to reality
Oh there goes gravity”
(Eminem, 8 Mile Soundtrack)

„ no physical embodiment Æ software obeys no physical laws

„ developer creates the laws Æ prescriptive rules

z unlike nature, we’re unable to understand all aspects of complexity
z rules often laid down unwittingly

„ to reason about software, need formal models and proofs

z rules formulated relative to abstract model of the software
z model does not completely describe the behavior of the running
system (hardware, operating system, runtime libraries, etc.)
z many states that are physically possible (i.e., bit configurations
allowed by the laws of physics) do not correspond to any state in
the abstract model (i.e., they are invalid bit configurations) Æ need
laws that constrain these transitions

5 © 2003 George Candea

Examples

„ limitations of careful specification

z scale (sys and env)
z synchronization w/ real system

„ limitations of post-spec formal methods

„ running time analysis for algorithms

z O(n) = a·n + constant
z O(n) is better than O(n2) ?

6 © 2003 George Candea

Parallel: Social Sciences

„ social sciences deal with people

z act according to as-yet unknown laws

„ Maurice Wilkes: “a scientist peels layers off nature,

while an engineer makes something happen”

7 © 2003 George Candea

Physics of Software

„ we need laws in software that we lay down and

enforce regardless (forget optimizations)
z “optimization is the art of taking something that works and
transforming it into something that’s cheaper and sort of
works” (Roger Needham)

„ enforced externally to the systems (e.g., by

hardware, such as perfect FD)

„ supernatural powers in sw:

z wall crashes Æ need to rebuild
z process crashes Æ ...

8 © 2003 George Candea

 Output Law:
Enforce abstractions just outside the
boundary of the providing system.

9 © 2003 George Candea

Abstractions
„ abstraction: a simplification of something much more complicated that is going
on under the covers
„ Abstractions in the physical domain:
A767/A767M-00b Standard Zinc-Coated Steel W-Beam Guard Rail

z architect and construction workers know properties, not quantum mechanics

„ Software domain
z abstractions allow us to deal with new orders of complexity in software development
„ GUI programming (windows instead of pixels)
„ network programming (sockets instead of bits)
„ databases (SQL instead of bits)
z TCP built on top of IP Æ TCP obliged to send data reliably using an unreliable tool

10 © 2003 George Candea

Leaky Abstractions
„ Examples
z physical link failure Æ network leaks through the TCP abstraction
z iterate over a large 2d array Æ different performance depending on direction
z home directories on NFS-mounted drives (one abstraction), users create .forward files
to forward all their email somewhere else (another abstraction); NFS server goes down
while new email is arriving, messages will not be forwarded because the .forward file
will not be found. Leak Æ a few messages got dropped on the floor

„ when abstraction leaks, it takes the VB programmer 2 weeks to figure his way
out of tar
„ Law of Leaky Abstractions: All non-trivial abstractions, to some degree, are
leaky. (Joel Spolsky)
„ when you train someone to be a C++ programmer, it would be nice to not have
to teach her about char*'s and pointer arithmetic; but one day she'll write "foo"
+ "bar"
„ even with higher and higher level programming tools with better and better
abstractions, becoming a proficient programmer is getting harder and harder
z R.P. Gabriel, Objects Have Failed (OOPSLA 2002): “in OO programming, failures are
called exceptions; in the real world they are called that's life”

11 © 2003 George Candea

Law 1: Enforce Abstractions

„ enforce spec over the result

„ often much easier to verify than to compute

„ Example 1:
z sorted array
z regardless of quicksort, bubblesort, foobarsort, ...

„ Example 2:
z statistical sampling
z run system in virtual machine

12 © 2003 George Candea

 Input Law:
Shape input quality and load just outside
the boundary of the accepting system.

13 © 2003 George Candea

Law 2: Load Shaping and Admission Control

„ fuse in a circuit
z impossible to have higher potential drop if no physical
changes to system

„ load on a bridge
z work in additional tolerance

„ circuit built for a certain

spec’d input Æ enforce spec

„ processing limitation:
deny access early

14 © 2003 George Candea

 Failure Law:
Coerce all subsystem failures into one of a
small set of expected failures.

15 © 2003 George Candea

Law 3: Fault Model Enforcement
„ coerce unknown behavior into known behavior

„ minor perturbations can throw entire system off

„ cannot have perfect cognition Æ enforce what you think

happened, i.e., the imperfect cognition
Æ if you can’t know it, make it happen
z I think node has crashed; let me make sure that’s true
z at-most-once and at-least-once delivery

„ key: benefit of enforcing suspicion should exceed drawback of

mistakenly enforcing wrong suspicions

„ Examples:
z coerce unknown failures into crashes (Rutgers FME)
z coerce timeouts into crashes

16 © 2003 George Candea

 Consumption Law:
Set and enforce resource usage limits; coerce
overutilization into known failure.

17 © 2003 George Candea

Resource Util.

Nov 5 21:15:32 rr3 kernel: Call Trace:

[<c01317e2>] add_to_page_cache_unique [kernel] 0x42 (0xc3cbbeec))
Nov 5 21:15:32 rr3 kernel: [<c013d655>] add_to_swap_cache [kernel] 0x85 (0xc3cbbefc))
Nov 5 21:15:32 rr3 kernel: [<c013d6e1>] add_to_swap [kernel] 0x41 (0xc3cbbf18))
Nov 5 21:15:32 rr3 kernel: [<c0139f94>] launder_page [kernel] 0x564 (0xc3cbbf34))
Nov 5 21:15:32 rr3 kernel: [<c013ad9c>] rebalance_dirty_zone [kernel] 0x5c (0xc3cbbf50))
Nov 5 21:15:32 rr3 kernel: [<c013ae7c>] rebalance_inactive_zone [kernel] 0x9c (0xc3cbbf70))
Nov 5 21:15:32 rr3 kernel: [<c013aeff>] rebalance_inactive [kernel] 0x3f (0xc3cbbf90))
Nov 5 21:15:32 rr3 kernel: [<c013b041>] do_try_to_free_pages_kswapd [kernel] 0x51 (0xc3cbbfb4))
Nov 5 21:15:32 rr3 kernel: [<c013b2b3>] kswapd [kernel] 0x83 (0xc3cbbfd4))
Nov 5 21:15:32 rr3 kernel: [<c013b230>] kswapd [kernel] 0x0 (0xc3cbbfe4))
Nov 5 21:15:32 rr3 kernel: [<c010727d>] kernel_thread_helper [kernel] 0x5 (0xc3cbbff0))
Nov 5 21:15:32 rr3 kernel:
Nov 5 21:15:32 rr3 kernel:
Nov 5 21:15:32 rr3 kernel: Code: 0f 0b 60 00 c0 b8 25 c0 8b 46 18 a9 00 02 00 00 74 08 0f 0b

18 © 2003 George Candea

Law 4: Control Resources

„ software rejuvenation

„ leases (DHCP, CPU, ...)

„ market-based schemes for memory, disk, etc.

19 © 2003 George Candea

Turning Laws into Design

„ approach:
1. state desired law
2. design enforcement mechanism
3. find ways to make system more amenable to enforcement

z build in mechanisms for quantifying effects of

physics enforcement

z properties/behavior should be immutable in the

absence of “physical” contact

20 © 2003 George Candea