Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Chris Blinn

dblp:31/10322 · DBLP profile ↗
← Back
2ranked-venue papers
0as first author
0since 2021 · last 2011
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 2

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
1 paper
Concurrent programming · 44% Debugging and program repair · 44% Operating systems · 13%

Topics — the 3 heaviest of 4, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Concurrent programming › concurrency bug detection
data race detection
0.112011
Pervasive detection of process races in deployed systems · SOSP 2011
Debugging and program repair
fault localization
0.112011
Pervasive detection of process races in deployed systems · SOSP 2011
Operating systems › operating system interface › system call
system call interposition
0.012011
Pervasive detection of process races in deployed systems · SOSP 2011

Methods — techniques the papers use, named apart from their topics

record and replay · 0.1deterministic replay · 0.1
YearPublicationVenuePosition
2011 Finding Concurrency Errors in Sequential Code - OS-level, In-vivo Model Checking of Process Races
Oren Laadan, Chia-Che Tsai, Nicolas Viennot, Chris Blinn, Peter Senyao Du, Jason Nieh
HotOS4
2011 Pervasive detection of process races in deployed systems
abstract
Process races occur when multiple processes access shared operating system resources, such as files, without proper synchronization. We present the first study of real process races and the first system designed to detect them. Our study of hundreds of applications shows that process races are numerous, difficult to debug, and a real threat to reliability. To address this problem, we created RacePro, a system for automatically detecting these races. RacePro checks deployed systems in-vivo by recording live executions then deterministically replaying and checking them later. This approach increases checking coverage beyond the configurations or executions covered by software vendors or beta testing sites. RacePro records multiple processes, detects races in the recording among system calls that may concurrently access shared kernel objects, then tries different execution orderings of such system calls to determine which races are harmful and result in failures. To simplify race detection, RacePro models under-specified system calls based on load and store micro-operations. To reduce false positives and negatives, RacePro uses a replay and go-live mechanism to distill harmful races from benign ones. We have implemented RacePro in Linux, shown that it imposes only modest recording overhead, and used it to detect a number of previously unknown bugs in real applications caused by process races.
Oren Laadan, Nicolas Viennot, Chia-Che Tsai, Chris Blinn, Jason Nieh
SOSP4