1 / 17

Concurrency as an Approach to Unification

This paper explores the use of concurrency as a unification framework for verifying the correctness of implementations in a concurrent environment. It discusses issues in both sequential and concurrent verification and proposes a modular verification approach. The paper also presents an example of mutual exclusion and illustrates the use of relational specification to abstract concurrency. The paper concludes by discussing client obligations and ensuring progress in the system.

askaggs
Download Presentation

Concurrency as an Approach to Unification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Encapsulating Concurrency as an Approach to Unification Santosh Kumar, Bruce W. Weide, Paolo A. G. Sivilotti The Ohio State University Nigamanth Sridhar Cleveland State University Jason O. Hallstrom Clemson University Scott M. Pike Texas A&M University

  2. Modular Verification • Prove the correctness of an implementation of a component using only the specification of its environment. SAVCBS 2004

  3. Sequential Framework Assume a single thread of execution Collection of passive objects makes up the environment Think of the environment behavior in terms of Hoare-style pre- and post-conditions, weakest pre-conditions,etc. Concurrent Framework Explicitly acknowledge the existence of multiple, concurrently executing threads Collection of active objects makes up the environment Think of the environment behavior in terms of Rely Guarantees, Hypothesis Conclusion, TLA, IOAutomata,etc. Framework Choice SAVCBS 2004

  4. The Unification Problem (Concurrent Verification Framework) • Major issues in sequential verification • Contract style to use • Impact of pointers, references, aliasing, etc. • How to reason about inheritance? • Major issues in concurrent verification • Deadlock detection and avoidance • Choice of synchronization primitives • Scheduling of processes • Protocol verification Modern Systems (Sequential Verification Framework) SAVCBS 2004

  5. Our Approach • Extend a sequential verification framework (RESOLVE) to the domain of concurrent systems SAVCBS 2004

  6. Example: Mutual Exclusion Client 1 Client 2 • Several clients wanting mutually exclusive access to a resource • The environment for clients is no longer passive • Clients are aware of the existence of other concurrently executing clients in the system • Clients negotiate with each other on mutually exclusive access to the resource. • Clients can’t use Sequential Verification Framework R Mutex SAVCBS 2004

  7. Facilitating a Solipsistic View • New description that simplifies semantics for the clients • Each client “thinks” • it is the only thread of execution, and • every change to the state of the environment is a result of its own actions. • The state of the environment never changes spontaneously. SAVCBS 2004

  8. Detailing Our Approach • Separation of a concurrent access component into a proxy component and a core component • Proxy component presents a sequential interface to the clients of a concurrent access component • How to abstract the inherent concurrency in a sequential spec (of Proxy)? • Solution: Use relational specification • How to ensure that the system behavior remains the same? • Solution: A special relation between the Proxy and the Core – “hides concurrency inherent in” SAVCBS 2004

  9. Illustration of Our Approach Client 1 Client 2 procedure Request () requires not self.requested ensures there exists i: NATURAL_NUMBER such that (self = (true, false, i)) expects self.Release() procedure Request (evaluates id: Integer) requires id is in self.all_proxies and not IS_REQUESTED(id, self.waiting_proxies) ensures self.all_proxies = #self.all_proxies and there exists ticket: NATURAL_NUMBER such that ((if #self.waiting_proxies = {} then (ticket = 0 and self.current_id = id) else (ticket > MIN_TICKET(self.waiting_proxies) and self.current_id = #self.current_id)) and self.waiting_proxies = #self.waiting_proxies union {(id, ticket)}) expects self.Release(id) Request() Request() Release() Release() Check_If_Available() Check_If_Available() R R Mutex_Proxy Mutex_Proxy Request() Request() Release() Release() Check_If_Available() Check_If_Available() R Mutex_Core SAVCBS 2004

  10. Abstracting the Concurrency procedure Request () requires not self.requested ensures there exists i: NATURAL_NUMBER such that (self = (true, false, i)) expects self.Release() procedure Check_If_Available (replaces b: Boolean) requires self.requested Ensures self.requested and (if #self.wait_index /= 0 then self.wait_index < #self.wait_index else #self.wait_index = self.wait_index) and b = self.available = (self.wait_index = 0) • Relational Specification • procedure Request() • A counter, wait_index, is initialized to some natural number value that cannot be observed • procedure Check_If_Available(ans) • Every call results in a decrease of wait_index by a positive amount. • The client gets access to the resource when wait_indexhits 0. • Clients can reason about their progress using a sequential verification framework. SAVCBS 2004

  11. Specifying Client Obligations • What happens if some client does not relinquish the resource (by calling Release())? • The progress of all waiting clients is jeopardized • Solution • Introduce a new “expects” clause • It encodes the obligations a client has towards its environment. • The obligations are picked up while calling some operations. • The mathematical structure for the “expects” is a set of method calls that the client promises to make in future. SAVCBS 2004

  12. Illustrating the “expects” Clause • A client must release the resource. • procedure Request() • expects • self.Release() SAVCBS 2004

  13. Summarizing the Contributions • Goal : To present a sequential interfaceto the clients of a concurrent-access component • Extract a sequential “proxy” specification from a concurrent-access component • Use relational specifications to abstract the effects of concurrency • Introduce “expects” clause to formalize the client obligations SAVCBS 2004

  14. Benefits of Our Approach • The effects of concurrency do not bleed through to the client • Client verification can be carried out using a sequential verification framework • Many client components are possible, all of whom benefit from this approach • The effects of concurrency are limited to just one component, the proxy component • Moreover, because of the “hides concurrency inherent in” relation between the proxy and the core, the proof of proxy implementation is not too complicated either • Illustrated by the proof for Mutex_Proxy implementation in the paper SAVCBS 2004

  15. Addressing the Unification Problem (Concurrent Verification Framework) Our Goal UNITY Seuss Model Checking RESOLVE (Sequential Verification Framework) SAVCBS 2004

  16. Open Issues • The “expects” clause • Its mathematical structure – multi-set, string, or some other model instead of a set? • Proof obligations for a non-terminating client • Application of our approach to cooperative concurrent systems • Proof system for verifying the correctness of corecomponent implementations SAVCBS 2004

  17. More Questions and Comments? SAVCBS 2004

More Related