Results 1 -
4 of
4
Static Data Race Detection for Concurrent Programs with Asynchronous Calls
"... A large number of industrial concurrent programs are being designed based on a model which combines threads with event-based communication. These programs consist of several threads which perform computation by dispatching tasks to other threads via asynchronous function calls. These asynchronous fu ..."
Abstract
- Add to MetaCart
A large number of industrial concurrent programs are being designed based on a model which combines threads with event-based communication. These programs consist of several threads which perform computation by dispatching tasks to other threads via asynchronous function calls. These asynchronous function calls are implemented using function objects, which are essentially wrappers containing a pointer to the function that should be executed on a particular thread with the corresponding arguments. In many cases, the arguments, in turn, contain function objects which serve as callbacks. Verifying such programs which involves reasoning about complex concurrency constructs comprising function pointers and callback functions is extremely tricky especially in the presence of recursion. In this paper, we present a fast and accurate static data race detection technique for multi-threaded C programs with asynchronous function calls and demonstrate its application to real-life software. 1.
Open
"... We revisit the device-driver architecture supported by the majority of operating systems, where a driver is a passive object that does not have its own thread of control and is only activated when an external thread invokes one of its entry points. This architecture complicates driver development an ..."
Abstract
- Add to MetaCart
We revisit the device-driver architecture supported by the majority of operating systems, where a driver is a passive object that does not have its own thread of control and is only activated when an external thread invokes one of its entry points. This architecture complicates driver development and induces errors in two ways. First, since multiple threads can invoke the driver concurrently, it must take care to synchronise the invocations to avoid race conditions. Second, since every invocation occurs in the context of its own thread, the driver cannot rely on programming-language constructs to maintain its control flow. Both issues make the control logic of the driver difficult to implement and even harder to understand and verify. To address these issues, we propose a device-driver architecture where each driver has its own thread of control and communicates with other threads in the system via message passing. We show how this architecture addresses both of the above problems. Unlike previous message-based driver frameworks, it does not require any special language support and can be implemented inside an existing operating system as a kernel extension. We present our Linux-based implementation in progress and report on preliminary performance results.
ERRATA TO THE POPL’09 PAPER “VERIFYING LIVENESS OF ASYNCHRONOUS PROGRAMS”
"... Abstract. An error was discovered by M.F. Atig in the coverability graph based decision procedure we defined in [2]. We thank him for bringing the error to our knowledge. We refer the interested reader to [1] for updated results about the verification of liveness properties for asynchronous programs ..."
Abstract
- Add to MetaCart
Abstract. An error was discovered by M.F. Atig in the coverability graph based decision procedure we defined in [2]. We thank him for bringing the error to our knowledge. We refer the interested reader to [1] for updated results about the verification of liveness properties for asynchronous programs. We show below at Fig. 1 and 2 that the coverability graph does not provide enough precision to determine the existence of fair infinite runs. main () { b:=false; while(NONDET) { post h1(); loc1 post h2(); loc2 h1() { b:=true; init loop exit h1 h2 d F 1 d F 2 bF dT d 2 T 1 bT h2() { if (b==true) post h2(); dloc Figure 1. An asynchronous program and its PN counterpart which has a fair infinite run init loop i exit d F 1 (d T 1) i−1 (d T 2) ω. 1 2 PIERRE GANTY, RUPAK MAJUMDAR, AND ANDREY RYBALCHENKO
AC: Composable Asynchronous IO for Native Languages
"... This paper introduces AC, a set of language constructs for composable asynchronous IO in native languages such as C/C++. Unlike traditional synchronous IO interfaces, AC lets a thread issue multiple IO requests so that they can be serviced concurrently, and so that long-latency operations can be ove ..."
Abstract
- Add to MetaCart
This paper introduces AC, a set of language constructs for composable asynchronous IO in native languages such as C/C++. Unlike traditional synchronous IO interfaces, AC lets a thread issue multiple IO requests so that they can be serviced concurrently, and so that long-latency operations can be overlapped with computation. Unlike traditional asynchronous IO interfaces, AC retains a sequential style of programming without requiring code to use multiple threads, and without requiring code to be “stack-ripped” into chains of callbacks. AC provides anasync statement to identify opportunities for IO operations to be issued concurrently, a do..finish block that waits until any enclosed async work is complete, and a cancel statement that requests cancellation of unfinished IO within an enclosing do..finish. We give an operational semantics for a core language. We describe and evaluate implementations that are integrated with message passing on the Barrelfish research OS, and integrated with asynchronous file and network IO on Microsoft Windows. We show that AC offers comparable performance to existing C/C++ interfaces for asynchronous IO, while providing a simpler programming model.

