Scribd Logo
Upload

Welcome to Scribd!

  • 27 views

    Project

    Uploaded by

    receiver618
    This document proposes a tool that uses dynamic analysis to help programmers write better concurrent code. It would instrument code as it runs, monitor for concurrency issues, and return a list of potential problems to the developer. Plugins would detect specific issues like data races, atomicity violations, and potential deadlocks. The tool's goals are to build the instrumentation and plugin framework, implement at least three plugins, and export issue reports in XML format.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd

    Project

    Uploaded by

    receiver618
    27 views2 pages
    This document proposes a tool that uses dynamic analysis to help programmers write better concurrent code. It would instrument code as it runs, monitor for concurrency issues, and return a list of potential problems to the developer. Plugins would detect specific issues like data races, atomicity violations, and potential deadlocks. The tool's goals are to build the instrumentation and plugin framework, implement at least three plugins, and export issue reports in XML format.

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document proposes a tool that uses dynamic analysis to help programmers write better concurrent code. It would instrument code as it runs, monitor for concurrency issues, and return a list of potential problems to the developer. Plugins would detect specific issues like data races, atomicity violations, and potential deadlocks. The tool's goals are to build the instrumentation and plugin framework, implement at least three plugins, and export issue reports in XML format.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    27 views2 pages

    Project

    Uploaded by

    receiver618
    This document proposes a tool that uses dynamic analysis to help programmers write better concurrent code. It would instrument code as it runs, monitor for concurrency issues, and return a list of potential problems to the developer. Plugins would detect specific issues like data races, atomicity violations, and potential deadlocks. The tool's goals are to build the instrumentation and plugin framework, implement at least three plugins, and export issue reports in XML format.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 2

    Home

    Syllabus

    Projects

    People

    I2CS Specific Information

    View

    Edit

    Dashboard > CS 527 Fall 2011 > Home > Projects > Guiding Programmers to Better Concurrent Code Through Dynamic Analysis

    Guiding Programmers to Better Concurrent Code Through Dynamic Analysis


    Motivation
    Writing concurrent code is hard, and developers may not even be aware of potential issues when they are writing new code that may be accessed by multiple threads. Developers tend to think serially when writing code, and this basic assumption may lead them to write code that has issues with regard to data races or atomicity violations, even when these issues may be avoided if the code were written with concurrent access in mind.

    Premise
    My proposal is to implement a tool which utilizes dynamic analysis to instrument code, monitor areas of interest with regard to concurrency, perform analysis, and return to the developer a list of potential issues they may wish to investigate further. The idea is this tool is to dynamic analysis of concurrent code what FindBugs is to static analysis of more general issues. Similar to the plugin based approach of FindBugs, this tool would utilize a plugin approach to detection of concurrency concerns. Each plugin would have the ability to put its finding inside a topic/category, and provide a severity level. For instance, one plugin may simply watch for data races among threads. This plugin would likely report a number of issues, but would categorize them appropriately and mark the severity level -- giving the developer the ability to quickly glance over the list or skip this portion of the analysis entirely. Another plugin, a potential deadlock detector, may watch for threads that at different times have acquired various locks in reverse order, and yield a result with an appropriate topic and a higher severity level.

    Goals
    The basic goals are as follows: Find or build an instrumentation layer so plugins can be notified of relevant operations (Using ReEx if it works out) Build a simple middle layer which: Looks for plugins and pulls them in Calls into plugins when instrumentation yields relevant operations Allows plugins to report a finding of interest, along with topic and severity Allows plugins to optionally report an example of the concurrency issue so the developer can more easily understand the topic Implement at least three plugins

    One indicating potential violations of atomicity in the code One indicating data races in the code One indicating potential deadlock scenarios based on lock acquisition order Export the reported issues in XML format, along with a very basic viewer for the XML.

    Adaptavist Theme Builder Adaptavist Theme Builder (4.2.2) Powered by Atlassian Confluence 3.4.9, the Enterprise Wiki

    You might also like