on Program Analysis Weizmann Institute of Science Guy Katz and David Harel Overview Program analysis verification repair synthesis etc Very desirable but very difficult State explosion ID: 415242
Download Presentation The PPT/PDF document "On Concurrency Idioms and their Effect" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
On Concurrency Idioms and their Effect on Program Analysis
Weizmann Institute
of Science
Guy Katz
and David
HarelSlide2
OverviewProgram analysis: verification, repair, synthesis,
etc
Very desirable, but very difficultState explosionHow can we make analysis more scalable?2Slide3
Improving Scalability
Traditional focus: more efficient algorithmsSymbolic model
checkingAbstraction / refinementCompositional verificationAnd many othersOur focus: how to choose the modeling language in a way that improves scalability
A design for analysis approach3Slide4
Choosing a Computational Model
Goal: tailor a model for the task at hand
Example: which programming models facilitate verification?Intuitively: DFA easier to verify than
++But programmers prefer ++A tradeoffCan we quantify it?
4Slide5
Our Goal
5
Focus on individual concurrency idiomsIdioms define inter-thread communication Which idioms are amenable to analysis? When?
Retain just enough concurrency: keep things simple!
Idiom A
Idiom B
Idiom C
Idiom D
Idiom E
Easy to analyzeSlide6
Example:
Program RepairSlide7
Program RepairA bug is found in existing software. Now what?
Manual repair
is difficultAutomation is much needed7Slide8
Repair Using BlockingBlocking: threads prohibit actions by other threads
Very useful in repair
Safety bugs: something bad happensUse blocking to prevent erroneous runsLiveness bugs: good things may never happenUse blocking to steer the execution towards good states
Patches are non-intrusive8
"
Non-Intrusive Repair of Safety and Liveness Violations
in Reactive
Programs
",
TCCI, 2014Slide9
Some states are marked bad
Finally, add a thread (“patch”) that blocks these edges
Simple Safety Repair
Slide10
Additional TopicsCompositional verification
In some cases, simple idioms facilitate assume/guarantee reasoning
Can even allow for automation (see talk later today)SuccinctnessSimple idioms are enough to write small programsJust as strong as very liberal modelsAutomatic optimization of the programRelax certain synchronization constraints, while maintaining the program’s semantics
10Slide11
11
Thank You!