Using program closures to make an application programming interface (API) implementation thread safe

Farchi, Eitan; Segall, Itai; Lourenço, João; Sousa, Diogo

doi:10.1145/2338967.2336810

Cited by 2 publications

(1 citation statement)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…An additional refinement to the notion of high-level data races was introduced by Pessanha in [10], relaxing the properties defined by Artho, which results in a higher precision of the analysis. Farchi et al [11] propose a methodology to detect atomicity violations in the usage of modules based on the definition of high-level data races. Another common type of atomicity violations that arise when sequencing several atomic operations are stale value errors.…”

Section: Related Workmentioning

confidence: 99%

Preventing Atomicity Violations with Contracts

Sousa,

Dias,

Ferreira

et al. 2015

Preprint

Self Cite

View full text Add to dashboard Cite

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.

show abstract

Section: Related Workmentioning

confidence: 99%