COMP 3000 Essay 2 2010 Question 7: Difference between revisions
Created page with " ---- See discussion" |
Added Intro/Research Problem and possible essay skeleton |
||
Line 1: | Line 1: | ||
==Paper== | |||
===Ad Hoc Synchronization Considered Harmful=== | |||
Weiwei Xiong | |||
University of California, San Diego | |||
-- | Soyeon Park, Jiaqi Zhang, Yuanyuan Zhou | ||
University of Illinois at Urbana-Champaign | |||
Zhiqiang Ma | |||
Intel | |||
==Research Problem== | |||
As the computer industry continues to shift towards multicore processors, concurrent programming and the use of multithreaded designs has increased to keep up with this growing trend. Multithreaded applications can be found in a variety of popular applications today as they take advantage of the multithreaded approach. However, the concepts behind concurrent programming bring with them a host of potential dangers in the form of race conditions and deadlocks resulting from bad programming design and threads accessing shared memory. Fortunately, there are well known and standard methods for dealing with these problems, i.e synchronization primitives. But in real world situations, due to a variety of reasons, as we shall see, programmers often implement their own "ad hoc" synchronizations that eschew common design standards. Ad hoc synchronizations are not well documented and are not discovered by traditional tools for race conditions that look for standard synchronization primitives. | |||
This paper addresses these concerns in two regards, first it details a thorough study of ad hoc synchronizations. It details their nature, dangers, impact on bug detection tools and prevalence in several major open-source applications. Secondly, it introduces SyncFinder, a program that detects all ad hoc synchronizations and automatically annotates the source code where ad hoc sychnronizations are found. This can see use in conjunction with other data race checkers to improve accuracy and to build custom tools for finding deadlocks and bad programming practices. | |||
With detailed analysis of ad hoc synchronization and study of their occurrences in several applications, the research ultimately concludes that they are harmful and should be removed. At the same time, SyncFinder detects and documents ad hoc synchronizations in the source code enabling programmers for the first time to easily track and remove them. | |||
==Background Concepts== | |||
===Race conditions, deadlocks=== | |||
===Ad Hoc Synchronization=== | |||
===Synchronization primitives=== | |||
==Contribution== | |||
Intro to the study of the major applications and what they found | |||
===Findings=== | |||
1.they are prevalent, all applications had them | |||
2. hard to find | |||
3. error prone | |||
4.effect other bug detection | |||
5. They are diverse. Different forms, multiple exits and dependencies | |||
Reasons behind why people use ad hoc synchronization and possible improvements over them ie Synchronization primitives | |||
===SyncFinder=== | |||
Intro to what it is and what it does | |||
====How it works==== | |||
1. find loops | |||
2. identify sync loops | |||
3. EDV analysis | |||
4. Pruning | |||
5. Annotation of found sync | |||
====Uses==== | |||
1. A tool to detect bad practices | |||
2. Extensions to data race detection | |||
====Accuracy==== | |||
====Related Work and similar tools==== | |||
==Critique== | |||
1. Uses static approach, dynamic would be better | |||
2. not entirely accurate, some false positives. | |||
Example footnote<sup>[[#Foot1|1]]</sup> | |||
==References== | |||
<span id="Foot1"><sup>1</sup> Author, 2010. Title. [online] Company(optional) Available at: <http://www.google.com> [Accessed 13 October 2010].</span> |
Revision as of 05:58, 22 November 2010
Paper
Ad Hoc Synchronization Considered Harmful
Weiwei Xiong University of California, San Diego
Soyeon Park, Jiaqi Zhang, Yuanyuan Zhou University of Illinois at Urbana-Champaign
Zhiqiang Ma Intel
Research Problem
As the computer industry continues to shift towards multicore processors, concurrent programming and the use of multithreaded designs has increased to keep up with this growing trend. Multithreaded applications can be found in a variety of popular applications today as they take advantage of the multithreaded approach. However, the concepts behind concurrent programming bring with them a host of potential dangers in the form of race conditions and deadlocks resulting from bad programming design and threads accessing shared memory. Fortunately, there are well known and standard methods for dealing with these problems, i.e synchronization primitives. But in real world situations, due to a variety of reasons, as we shall see, programmers often implement their own "ad hoc" synchronizations that eschew common design standards. Ad hoc synchronizations are not well documented and are not discovered by traditional tools for race conditions that look for standard synchronization primitives.
This paper addresses these concerns in two regards, first it details a thorough study of ad hoc synchronizations. It details their nature, dangers, impact on bug detection tools and prevalence in several major open-source applications. Secondly, it introduces SyncFinder, a program that detects all ad hoc synchronizations and automatically annotates the source code where ad hoc sychnronizations are found. This can see use in conjunction with other data race checkers to improve accuracy and to build custom tools for finding deadlocks and bad programming practices.
With detailed analysis of ad hoc synchronization and study of their occurrences in several applications, the research ultimately concludes that they are harmful and should be removed. At the same time, SyncFinder detects and documents ad hoc synchronizations in the source code enabling programmers for the first time to easily track and remove them.
Background Concepts
Race conditions, deadlocks
Ad Hoc Synchronization
Synchronization primitives
Contribution
Intro to the study of the major applications and what they found
Findings
1.they are prevalent, all applications had them
2. hard to find
3. error prone
4.effect other bug detection
5. They are diverse. Different forms, multiple exits and dependencies
Reasons behind why people use ad hoc synchronization and possible improvements over them ie Synchronization primitives
SyncFinder
Intro to what it is and what it does
How it works
1. find loops
2. identify sync loops
3. EDV analysis
4. Pruning
5. Annotation of found sync
Uses
1. A tool to detect bad practices
2. Extensions to data race detection
Accuracy
Related Work and similar tools
Critique
1. Uses static approach, dynamic would be better
2. not entirely accurate, some false positives.
Example footnote1
References
1 Author, 2010. Title. [online] Company(optional) Available at: <http://www.google.com> [Accessed 13 October 2010].