Compiler Support for Distributed Systems Martin C Rinard

Compiler Support for Distributed Systems Martin C. Rinard University of California, Santa Barbara

Goal Provide Software Tools That Support Development of Components of Distributed Systems • Problems • Interoperability • Distributed Component Development • Components Developed At Different Times • Components Developed By Different Organizations • Interaction With People • Our Approach • Formal Interface Definitions Using Finite State Machines • Automated Interface Extraction, Verification and Testing • Novel Constructs for Building Robust User Interfaces

Model of Computation • Distributed Systems Built Out Of Components • Processes • Agents • Objects • Components Communicate Via Message Passing • Asynchronous Sends, In Order Delivery • send(component, message type, parameters) • Blocking Receives • recv(component? , message type, parameters? ) • Selection Construct

Example Customer ATM Machine Please Deposit $5, 000. 00 1 4 7 2 5 8 0 3 6 9. Bank

Scenario • Existing ATM System • Bank Contracts For New Kind of ATM • New ATM Must Interoperate With Existing Bank Software • ATM Developer Must Know Bank Interface • Bank Unwilling to Release Source Code

Bank Implementation loop { select { recv(atm? , DEPOSIT, account? , amount? ) -> { account. balance += amount; send(atm, OK); } recv(atm? , WITHDRAW, account? , amount? ) -> { if (amount < account. balance) { account. balance -= amount; send(atm, OK); } else { send(atm, FAILED); } } }}

Bank Interface • Message Type Information • • recv(component? , DEPOSIT, int? ) recv(component? , WITHDRAW, int) send(component, OK); send(component, FAILED); • Message Sequencing Information recv(atm? , DEPOSIT) send(atm, OK) recv(atm? , WITHDRAW) send(atm, FAILED) send(atm, OK)

Conformance of Components and Interfaces • Context • Have A Component (Bank Component) • Have An Interface (Bank Interface) • Does Component Correctly Implement Interface? • Analyze Program To Automatically Extract New Interface • Abstract Away From Computation • Translate Communication and Relevant Flow of Control Constructs Into Parts Of Finite State Machine • Does Extracted Interface Conform to Original Interface?

Automatic Interface Extraction • Individual Programming Constructs • if (exp) { send(c, OK); } else { send(c, OK); send(c, FAILED); } • select { recv(c? , OK) -> {} recv(c? , OK) recv(c? , FAILED) ->{} } • Interprocedural Interface Extraction Internal Choice send(c, FAILED); External Choice recv(c? , FAILED)

Basic Conformance Concepts • Concept Of Conformance • An Interface I Extracted From a Component • An Interface J That System Is Designed to Use • If I Conforms to J, Can Safely Use Component In System • If Every Message Sent Is Received With J, Every Message Sent Will Be Received With Component • A State S is Stable If It Is Not An Internal Choice Point • A State S is Receptive If It Can Only Receive Messages • Given Two Interfaces, Sets Of Corresponding States • Maximal Sets Of States Accessible Via Same Sequence of Sends and/or Receives

Corresponding Sets In Example Extracted Interface recv(atm? , DEPOSIT) recv(atm? , WITHDRAW) send(atm, OK) send(atm, FAILED) send(atm, OK) Original Interface recv(atm? , DEPOSIT) send(atm, OK) recv(atm? , WITHDRAW) send(atm, FAILED) send(atm, OK)

First Conformance Condition For Each Corresponding Set Of States Messages Sent From States In Extracted Interface Must Be A Subset of Messages Sent From States In Original Interface Extracted Interface send(c, OK) Original Interface send(c, FAILED) send(c, OK)

Second Conformance Condition For Each Corresponding Set Of States Messages Received In States In Extracted Interface Must Be A Subset of Messages Received In States In Original Interface recv(c? , FAILED) recv(c? , OK) Extracted Interface recv(c? , OK)

Third Conformance Condition For Each Corresponding Set Of States If Receptive States Of Original Interface Must Receive One Of A Set Of Messages, Receptive States Of The Extracted Interface Must Also Receive One Of That Set Of Messages Original Interface recv(c? , MSG) recv(c? , OK) Extracted Interface recv(c? , OK)

Final Conformance Conditions For Each Corresponding Set Of States • If Original Interface Always Sends A Message • Extracted Interface Must Always Send A Message • If Original Interface Always Reaches A Receptive State • Extracted Interface Must Always Reach A Receptive State • If Original Interface Always Reaches A Stable State • Extracted Interface Must Always Reach A Stable State

Does Extracted Interface Conform To Original Interface? Extracted Interface recv(atm? , DEPOSIT) recv(atm? , WITHDRAW) send(atm, OK) send(atm, FAILED) send(atm, OK) Original Interface recv(atm? , DEPOSIT) send(atm, OK) recv(atm? , WITHDRAW) send(atm, FAILED) send(atm, OK)

Implementing ATM • Interface Between Customer and Bank • Model Customer As Simply Another Component • Customer Actions Modeled As Message Sends • Physical Actions Translate Directly Into Message Sends • Example • Customer Pushes the Deposit Button • System Internally Generates send(atm, DEPOSIT) • Customer Hits 8 Digit On Keypad • System Internally Generates send(atm, DIGIT, 8)

ATM Primitives void get_amount(int * amount) { *amount = 0; loop { select { recv(DIGIT, &d) -> { *amount = (*amount * 10) + d; } recv(DONE) -> break; } } }

ATM Implementation loop { get_account(&account); select { recv(DEPOSIT) -> { get_amount(&amount); send(bank, DEPOSIT, account, amount); recv(bank? , OK)-> { Confirm Deposit } } recv(WITHDRAW) -> { get_amount(&amount); send(bank, WITHDRAW, account, amount); select { recv(bank? , OK) -> { Dispense Cash } recv(bank? , FAILED) -> { Generate Error Message } }}

ATM Message Type Information • User Actions • recv(DEPOSIT) • recv(WITHDRAW) • recv(DIGIT, int? ) • recv(DONE) • Sends To and Receives From Bank • send(bank, DEPOSIT, int) • send(bank, WITHDRAW, int) • recv(component? , OK) • recv(component? , FAILED)

ATM Message Sequence Information recv(FAILED) recv(DIGIT) recv(DONE) recv(OK) recv(DEPOSIT) recv(OK) recv(WITHDRAW) recv(DIGIT) recv(DONE) send(bank, DEPOSIT) send(bank, WITHDRAW)

Automated Testing And Verification • Compose Interfaces • Simulate to Derive All Possible System States • Flag Potentially Erroneous States • A Message Sent But Never Will Be Received • User Messages Treated Specially • Any Sequence of User Actions Possible • User Actions Processed Only In Quiescent System States

Simulation Reveals Potential Problem In Example • Customer May Back Out of Transaction • Customer Starts A Deposit • System Expects to Input Amount to Deposit • But Customer Hits Withdrawl Button • System Does Not Handle Event • Programming Mismatch • Programmers Reason With Expected Sequences, But • Program Must Correctly Handle Exceptional Sequences • Standard Constructs Do Not Support Construction of Robust User Interfaces

A Construct For Building Robust User Interfaces • Goals • Preserve Ability To Reason With Expected Sequences • Easily Augment Program For Exceptional Sequences • Reseting Select Construct • Same Syntax As Select • Same Behavior As Select For Expected Sequences • Unselected Receive Alternatives Stay Enabled • If Customer Generates Exceptional Action • Implementation Resets Active Alternative • Starts Newly Selected Alternative • Reset Actions - Executed When Alternative is Reset

Reseting Select Construct reset. Select { recv(DEPOSIT) -> { get_amount(&amount); send(bank, DEPOSIT, account, amount); recv(bank? , OK)-> { Confirm Deposit } } recv(WITHDRAW) -> { get_amount(&amount); send(bank, WITHDRAW, account, amount); select { recv(bank? , OK) -> { Dispense Cash } recv(bank? , FAILED) -> { Generate Error Message } } } recv(DIGIT, d? ) -> { Print Error Message } recv(DONE) -> { Print Error Message }

Comparison With Standard Methods • Event Loop • loop { wait_event(&e); process_event(e); } • System State Encoded in Global Variables • Demultiplexing Required To Determine Correct Action • Difficult To Determine if All Events Handled Correctly • Proposed Approach • Supports Use of Standard Program Constructs • Standard Flow of Control, Local State • Semantically Related Code Appears Together • Easy To Write Programs That Handle Events Correctly • Easy To Determine if All Events Handled Correctly

Conclusion • Program Analysis Techniques Can Help Programmers Develop Robust Distributed Systems • Include Sequencing Information in Interface • Automatic Interface Extraction • Automatic Verification of Interoperability • Interaction With User • Model User As Another Component • Novel Construct For Robust User Interfaces

Potential Scenarios • System Developed From Scratch • Developer of ATM Software Needs to Know • Bank Interface • Reasonable User Interface • Bank Software Developer Needs to Know ATM Interface • Bank Contracts For A New Kind of ATM • New ATM Will Interact With Existing Bank Software • ATM Software Developer Needs to Know Bank Interface • Bank Unwilling Release Source Code

ATM Message Sequence Information get_account recv(DEPOSIT) get_amount recv(WITHDRAW) get_amount recv(OK) send(bank, DEPOSIT) recv(OK) send(bank, WITHDRAW) recv(FAILED)

Interface Uses • Documentation During Development • To Test That Components Correctly Implement Interfaces • Analyze Program to Automatically Extract Interface • Test if Interfaces Are Equivalent • To Drive Automated Testing and Verification • Compose Components • Simulate to Derive All Possible System States • Flag Potentially Erroneous States • User Messages Treated Differently • Any Sequence of User Actions Possible • User Actions Processed Only In Quiescent States