Reference Manual for the ADA Programming Language
Reference Manual for the ADA Programming Language
Java(TM) Language Specification, The (3rd Edition) (Java (Addison-Wesley))
Java(TM) Language Specification, The (3rd Edition) (Java (Addison-Wesley))
Proceedings of the 32nd ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Threads cannot be implemented as a library
Proceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation
Automatically classifying benign and harmful data races using replay analysis
Proceedings of the 2007 ACM SIGPLAN conference on Programming language design and implementation
How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs
IEEE Transactions on Computers
Foundations of the C++ concurrency memory model
Proceedings of the 2008 ACM SIGPLAN conference on Programming language design and implementation
On Validity of Program Transformations in the Java Memory Model
ECOOP '08 Proceedings of the 22nd European conference on Object-Oriented Programming
x86-TSO: a rigorous and usable programmer's model for x86 multiprocessors
Communications of the ACM
Memory models: a case for rethinking parallel languages and hardware
Communications of the ACM
Adversarial memory for detecting destructive races
PLDI '10 Proceedings of the 2010 ACM SIGPLAN conference on Programming language design and implementation
Proceedings of the 37th annual international symposium on Computer architecture
Data races are evil with no exceptions: technical perspective
Communications of the ACM
You don't know jack about shared variables or memory models
Communications of the ACM
You Don't Know Jack about Shared Variables or Memory Models
Queue - Log Analysis
Data races vs. data race bugs: telling the difference with portend
ASPLOS XVII Proceedings of the seventeenth international conference on Architectural Support for Programming Languages and Operating Systems
Can seqlocks get along with programming language memory models?
Proceedings of the 2012 ACM SIGPLAN Workshop on Memory Systems Performance and Correctness
IFRit: interference-free regions for dynamic data-race detection
Proceedings of the ACM international conference on Object oriented programming systems languages and applications
CoRD: a collaborative framework for distributed data race detection
HotDep'12 Proceedings of the Eighth USENIX conference on Hot Topics in System Dependability
Position paper: nondeterminism is unavoidable, but data races are pure evil
Proceedings of the 2012 ACM workshop on Relaxing synchronization for multicore and manycore scalability
Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles
ACM SIGOPS 24th Symposium on Operating Systems Principles
RaceMob: crowdsourced data race detection
Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles
Concurrent predicates: a debugging technique for every parallel programmer
PACT '13 Proceedings of the 22nd international conference on Parallel architectures and compilation techniques
Concurrency testing using schedule bounding: an empirical study
Proceedings of the 19th ACM SIGPLAN symposium on Principles and practice of parallel programming
| Hi-index | 0.03 |
Several prior research contributions [15, 9] have explored the problem of distinguishing "benign" and harmful data races to make it easier for programmers to focus on a subset of the output from a data race detector. Here we argue that, although such a distinction makes sense at the machine code level, it does not make sense at the C or C++ source code level. n one sense, this is obvious: The upcoming thread specifications for both languages [6, 7] treat all data races as errors, as does the current Posix threads specification. And experience has shown that it is difficult or impossible to specify anything else. [1, 2] Nonetheless many programmers clearly believe, along with [15] that certain kinds of data races can be safely ignored in practice because they will produce expected results with all reasonable implementations. Here we show that all kinds of C or C++ source-level "benign" races discussed in the literature can in fact lead to incorrect execution as a result of perfectly reasonable compiler transformations, or when the program is moved to a different hardware platform. Thus there is no reason to believe that a currently working program with "benign races" will continue to work when it is recompiled. Perhaps most surprisingly, this includes even the case of potentially concurrent writes of the same value by different threads.