11,521 research outputs found
A systematic approach to atomicity decomposition in Event-B
Event-B is a state-based formal method that supports a refinement process in which an abstract model is elaborated towards an implementation in a step-wise manner. One weakness of Event-B is that control flow between events is typically modelled implicitly via variables and event guards. While this fits well with Event-B refinement, it can make models involving sequencing of events more difficult to specify and understand than if control flow was explicitly specified. New events may be introduced in Event-B refinement and these are often used to decompose the atomicity of an abstract event into a series of steps. A second weakness of Event-B is that there is no explicit link between such new events that represent a step in the decomposition of atomicity and the abstract event to which they contribute. To address these weaknesses, atomicity decomposition diagrams support the explicit modelling of control flow and refinement relationships for new events. In previous work,the atomicity decomposition approach has been evaluated manually in the development of two large case studies, a multi media protocol and a spacecraft sub-system. The evaluation results helped us to develop a systematic definition of the atomicity decomposition approach, and to develop a tool supporting the approach. In this paper we outline this systematic definition of the approach, the tool that supports it and evaluate the contribution that the tool makes
Preventing Atomicity Violations with Contracts
Software developers are expected to protect concurrent accesses to shared
regions of memory with some mutual exclusion primitive that ensures atomicity
properties to a sequence of program statements. This approach prevents data
races but may fail to provide all necessary correctness properties.The
composition of correlated atomic operations without further synchronization may
cause atomicity violations. Atomic violations may be avoided by grouping the
correlated atomic regions in a single larger atomic scope. Concurrent programs
are particularly prone to atomicity violations when they use services provided
by third party packages or modules, since the programmer may fail to identify
which services are correlated. In this paper we propose to use contracts for
concurrency, where the developer of a module writes a set of contract terms
that specify which methods are correlated and must be executed in the same
atomic scope. These contracts are then used to verify the correctness of the
main program with respect to the usage of the module(s). If a contract is well
defined and complete, and the main program respects it, then the program is
safe from atomicity violations with respect to that module. We also propose a
static analysis based methodology to verify contracts for concurrency that we
applied to some real-world software packages. The bug we found in Tomcat 6.0
was immediately acknowledged and corrected by its development team
- …