Parallel and Distributed Systems: Testing, Analysis, and Debugging最新文献

{"title":"Reproducible testing of distributed software with middleware virtualization and simulation","authors":"Cyril Briquet, Pierre-Arnoul de Marneffe","doi":"10.1145/1390841.1390842","DOIUrl":"https://doi.org/10.1145/1390841.1390842","url":null,"abstract":"P2P Grids are Grids organized into P2P networks where participant exchange computing time so as to complete computational tasks. Evaluating the performance of scheduling algorithms enables one to deploy those that are efficient. Performance is often evaluated experimentally or through simulation because these algorithms (typically heuristics) are too complex to model analytically. Testing the implementation of P2P Grid middleware before it is deployed is also important: Reproducing configurations or conditions that lead to unexpected outcomes is thus valuable.\u0000 A P2P Grid environment exhibits multiple sources of failure and is typically dynamic and uncontrollable. Reproducing even basic behavior of Grid nodes in a controllable and repeatable manner is thus exceedingly difficult. Such lack of control over the environment is a major challenge in the software engineering of P2P Grid middleware [7]. Simulators have been proposed to evaluate the performance of scheduling algorithms, but are often limited in scope, reusability and accuracy, i.e. they rely on simplified models.\u0000 We introduce a software engineering pattern - that we call code once, deploy twice - to both reduce the distance between simulated and implemented algorithms and reproduce, at will, Grid configurations and environments: A simulator implementation of a Grid architecture is built by virtualizing its middleware implementation. An immediate benefit is that most of the code can be reused between both implementations; only communications between Grid nodes, multithreading within Grid nodes and actual task execution are coded differently. As a derived benefit, most of the code of the middleware can be tested within the controlled environment of the simulator, before it is deployed as-is. Another benefit is high simulation accuracy. We describe the implementation of a P2P Grid following the code once, deploy twice pattern, that we believe is also relevant to other Grid types (certainly Volunteer Grids [5, 4] and Desktop Grids [22], and possibly Globus-based Grids [3]).","PeriodicalId":291507,"journal":{"name":"Parallel and Distributed Systems: Testing, Analysis, and Debugging","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-07-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130230379","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"On-the-fly race detection in multi-threaded programs","authors":"A. Jannesari, W. Tichy","doi":"10.1145/1390841.1390847","DOIUrl":"https://doi.org/10.1145/1390841.1390847","url":null,"abstract":"Multi-core chips enable parallel processing for general purpose applications. Unfortunately, parallel programs may contain synchronization defects. Such defects are difficult to detect due to nondeterministic interleavings of parallel threads. Current tools for detecting these defects produce numerous false alarms, thereby concealing the true defects. This paper describes an extended race detection technique based on a combination of lockset analysis and the happens-before relation. The approach provides more accurate warnings and significantly reduces the number of false positives, while limiting the number of false negatives. The technique is implemented in Helgrind+, an extension of the open source dynamic race detector Helgrind. Experimental results with several applications and benchmarks demonstrate a significant reduction in false alarms at a moderate runtime increase.","PeriodicalId":291507,"journal":{"name":"Parallel and Distributed Systems: Testing, Analysis, and Debugging","volume":"54 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-07-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126404693","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Scheduling considerations for building dynamic verification tools for MPI","authors":"S. Vakkalanka, Michael Delisi, G. Gopalakrishnan, R. Kirby","doi":"10.1145/1390841.1390844","DOIUrl":"https://doi.org/10.1145/1390841.1390844","url":null,"abstract":"Dynamic verification methods are the natural choice for formally verifying real world programs when model extraction and maintenance are expensive. Message passing programs written using the MPI library often fall under this category, especially when these programs have to be verified after being ported to new platforms and iteratively optimized. However, implementing dynamic verification tools for MPI requires solving many problems pertaining to the scheduling realities of the MPI runtime. In this paper, we describe the progression of our ideas during the development of our dynamic verification tool for MPI programs, called in-situ partial order (ISP). Each idea developed in this progression relates to our dual goals of ensuring full coverage of all representative interleavings (in the sense of partial order reduction) among MPI processes, and forcing the MPI runtime to affect these interleavings. We briefly examine similar issued faced by other builders of dynamic verification tools. We conclude with observations backing the growing importance of addressing scheduling issues in future dynamic verification tools for various concurrency APIs.","PeriodicalId":291507,"journal":{"name":"Parallel and Distributed Systems: Testing, Analysis, and Debugging","volume":"93 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-07-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"117182772","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Software development tools for multi-core/parallel programming","authors":"R. Peri","doi":"10.1145/1390841.1390850","DOIUrl":"https://doi.org/10.1145/1390841.1390850","url":null,"abstract":"The new era of multi-core processors is bringing unprecedented computing power to the mainstream desktop applications. In order to fully exploit this compute power one has to delve into the world of parallel programming which until today has been the exclusive domain of High Performance Computing Community. This talk will focus on the current state of the art in parallel programming tools that is applicable for developers of mainstream parallel applications with emphasis on software development tools like compilers, debuggers, performance analysis tools and correctness checking tools for parallel programs. I will share some of the challenges that developers face today in developing applications for multi-core systems containing a small number of homogeneous cores (2 to 8) and discuss the situation we will face with the advent of systems containing many more heterogeneous cores in next few years.","PeriodicalId":291507,"journal":{"name":"Parallel and Distributed Systems: Testing, Analysis, and Debugging","volume":"58 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-07-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131620380","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Support for symmetric shadow memory in multiprocessors","authors":"V. Nagarajan, Rajiv Gupta","doi":"10.1145/1390841.1390846","DOIUrl":"https://doi.org/10.1145/1390841.1390846","url":null,"abstract":"Runtime monitoring support serves as a foundation for the important tasks of providing security [15, 14, 2], performing debugging [13, 11, 8], and improving performance of applications [1]. Runtime monitoring, typically, requires the maintenance of meta data associated with each of the application's original memory location, which are held in corresponding shadow memory locations. Each original memory instruction (OMI) is then accompanied by additional shadow memory instructions (SMIs) that manipulate the meta data associated with the memory location. Often the SMIs associated with OMIs are symmetric, in that, original stores (loads) are accompanied by shadow stores (loads). Unfortunately, existing shadow memory implementations need thread serialization to ensure that OMIs and SMIs are executed atomically [12]. Naturally this is not an efficient approach, especially in the now ubiquitous multiprocessors.\u0000 In this paper, we present an efficient shadow memory implementation that handles symmetric shadow instructions. By coupling the coherency of shadow memory with the coherency of the main memory, we ensure that the SMIs execute atomically with their corresponding OMIs. We also couple the allocation of application memory pages with its associated shadow pages, for enabling fast translation of original addresses into corresponding shadow memory addresses. Our experiments show that the overheads of run-time monitoring tasks are significantly reduced in comparison to previous software implementations.","PeriodicalId":291507,"journal":{"name":"Parallel and Distributed Systems: Testing, Analysis, and Debugging","volume":"71 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-07-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127797470","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Dynamic testing of flow graph based parallel applications","authors":"B. Schaeli, R. Hersch","doi":"10.1145/1390841.1390843","DOIUrl":"https://doi.org/10.1145/1390841.1390843","url":null,"abstract":"In message-passing parallel applications, messages are not delivered in a strict order. The number of messages, their content and their destination may depend on the ordering of their delivery. Nevertheless, for most applications, the computation results should be the same for all possible orderings. Finding an ordering that produces a different outcome or that prevents the execution from terminating reveals a message race or a deadlock. Starting from the initial application state, we dynamically build an acyclic message-passing state graph such that each path within the graph represents one possible message ordering. All paths lead to the same final state if no deadlock or message race exists. If multiple final states are reached, we reveal message orderings that produce the different outcomes. The corresponding executions may then be replayed for debugging purposes. We reduce the number of states to be explored by using previously acquired knowledge about communication patterns and about how operations read and modify local process variables. We also describe a heuristic that tests a subset of orderings that are likely to reveal existing message races or deadlocks. We applied our approach on several applications developed using the Dynamic Parallel Schedules (DPS) parallelization framework. Compared to the naive execution of all message orderings, the use of a message-passing state graph reduces the cost of testing all orderings by several orders of magnitude. The use of prior information further reduces the number of visited states by a factor of up to fifty in our tests. The heuristic relying on a subset of orderings was able to reveal race conditions in all tested cases. We finally present a first step in generalizing the approach to MPI applications.","PeriodicalId":291507,"journal":{"name":"Parallel and Distributed Systems: Testing, Analysis, and Debugging","volume":"493 2","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-07-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"113982328","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Systematic concurrency testing using CHESS","authors":"M. Musuvathi","doi":"10.1145/1390841.1390851","DOIUrl":"https://doi.org/10.1145/1390841.1390851","url":null,"abstract":"Concurrency testing should aim for systematic coverage of thread interleavings. The most common method used today is stress testing, where the program is run under load with lots of threads. While this indirectly increases the variety of thread interleavings, the coverage is neither sufficient and nor predictable---stories are legend of the so-called \"Heisenbugs\" that rarely surface during testing and are very hard to debug.\u0000 In this talk, I will argue for a new notion of concurrency testing called scenario testing and describe CHESS, a tool we have developed towards that end. A user of CHESS provides simple concurrency scenarios and CHESS systematically enumerates all thread interleavings of these scenarios. CHESS employs model checking techniques to effectively focus on potentially bug-yielding schedules and provides sound quantifiable notions of coverage. On finding an error, CHESS has the capability to replay the erroneous interleaving, greatly simplifying the debugging process. CHESS has been successfully integrated with several codebases inside Microsoft and is used daily by the test teams. CHESS has found numerous bugs in systems that have been stress-tested for months. Additionally, CHESS has successfully reproduced many stress-test crashes that were previously hard to debug. The latter shows that many bugs that are found in stress-testing can indeed be reproduced in simple scenarios, a good validation for scenario testing.\u0000 CHESS is available for download at http://research.microsoft.com/CHESS. The talk will contain enough material to act as a tutorial for first-time users. I will also describe the challenges in applying CHESS to a new codebase and how to address them.","PeriodicalId":291507,"journal":{"name":"Parallel and Distributed Systems: Testing, Analysis, and Debugging","volume":"82 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-07-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129343606","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Memory tagging in Charm++","authors":"F. Gioachin, L. Kalé","doi":"10.1145/1390841.1390845","DOIUrl":"https://doi.org/10.1145/1390841.1390845","url":null,"abstract":"Many scientific applications are logically decomposed into modules. each module performing a different type of computation. These modules are then linked together inside the same executable. While these modules are logically independent, they are not physically independent: a faulty module can corrupt the state of another one.\u0000 By identifying the different modules inside an application, tagging the memory according to the different modules, and performing extra runtime checks, we can automatically detect certain type of errors. We implemented our idea inside the Charm++ runtime system, where modules can be easily identified. We illustrate the validity of our approach, and evaluate its overhead.","PeriodicalId":291507,"journal":{"name":"Parallel and Distributed Systems: Testing, Analysis, and Debugging","volume":"46 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-07-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134080885","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Pitfalls in teaching development and testing of concurrent programs and how to overcome them","authors":"E. Farchi","doi":"10.1145/1390841.1390852","DOIUrl":"https://doi.org/10.1145/1390841.1390852","url":null,"abstract":"This lecture captures industrial and academic experience in teaching concurrent programming for several years. While the statement of a concurrent protocol is typically small taking only a few pages to complete, the statement implicitly introduces an exponential or possibly infinite space of possible interleavings. The novice is not aware of this, and as a result sometimes does not understand the lecture. To overcome this pitfall, exploration of the protocol interleaving is practiced from day one. A classical example being how many results does 100 threads executing i++ have?\u0000 Separation of concerns is used to minimize the interleaving space at design time. Specifically, abstract primitives, such as atomic block and a conditional atomic block are introduced as a design tool. They are typically not to be found in practical programming languages. This reduces the space of interleavings to be considered at design time and facilitate verification and review of the protocol. On the other hand, the approach introduces pitfalls encountered in the translation/implementation stage.\u0000 Once the abstract design is verified and/or tested, it needs to be translated to a commercial language where the synchronization primitives, for performance reasons, are weaker. For example, an atomic block is implemented using a lock unlock pair. But now atomicity needs to be ensured by the protocol implementer---a typical pitfall being the confusion of a lock/unlock code segment with an atomic block. Locations in the code that access the protected shared resources should be identified and access needs to follow the lock/unlock protocol. Exceptions and signals needs to be handled appropriately and adhere to the lock/unlock protocol. To avoid translation pitfalls, bug patterns are taught and precise understanding of the synchronization primitives is emphasized.\u0000 Testing of the implemented protocol is taught. Testing should be aggressive, at unit test, and attempt to cover the interleaving space instead of common practice of testing concurrency at system test in a round about way through stress.\u0000 Tools like ConTest or CHESS can be applied to this end.","PeriodicalId":291507,"journal":{"name":"Parallel and Distributed Systems: Testing, Analysis, and Debugging","volume":"24 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-07-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134052685","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Testing patterns for software transactional memory engines","authors":"João M. Lourenço, Gonçalo Cunha","doi":"10.1145/1273647.1273655","DOIUrl":"https://doi.org/10.1145/1273647.1273655","url":null,"abstract":"The emergence of multi-core processors is promoting the use of concurrency and multithreading. To raise the abstraction level of synchronization constructs is fundamental to ease the development of concurrent software, and Software Transactional Memory (STM) is a good approach towards such goal. However, execution environment issues such as the processor instruction set, caching policy, and memory model, may have strong influence upon the reliability of STM engines. This paper addresses the testing of STM engines aiming at improving their reliability and independence from execution environment. From our experience with porting and extending a specific STM engine, we report on some of the bugs found and synthesize some testing patterns that proved to be useful at testing STM engines.","PeriodicalId":291507,"journal":{"name":"Parallel and Distributed Systems: Testing, Analysis, and Debugging","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2007-07-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115170624","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}