Nekara: Generalized Concurrency Testing - Microsoft
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Nekara: Generalized Concurrency Testing
Udit Agarwal* , Pantazis Deligiannis+ , Cheng Huang++ , Kumseok Jung** , Akash Lal+ , Immad Naseer++
Matthew Parkinson+ , Arun Thangamani+ , Jyothi Vedurada# , Yunpeng Xiao++
*
IIIT Delhi, + Microsoft Research, ++
Microsoft, **
University of British Columbia, # IIT Hyderabad
Abstract—Testing concurrent systems remains an uncomfort- algorithmic search: a collection of heuristics that guide the
able problem for developers. The common industrial practice is search to interesting parts where bugs can be found, for
to stress-test a system against large workloads, with the hope instance, fewer context switches first [3], or priority-based
of triggering enough corner-case interleavings that reveal bugs.
However, stress testing is often inefficient and its ability to get scheduling [4], etc. Second is the modeling of supported con-
coverage of interleavings is unclear. In reaction, the research currency primitives that specify their semantics, for instance,
community has proposed the idea of systematic testing, where a the behavior of spawning a thread or acquiring a semaphore,
tool takes over the scheduling of concurrent actions so that it can etc. Last is the injection of these models into a program so
perform an algorithmic search over the space of interleavings. that calls to the original primitives can be replaced by calls
We present an experience paper on the application of systematic
testing to several case studies. We separate the algorithmic to their corresponding models, helping take over scheduling
advancements in prior work (on searching the large space of decisions at runtime.
interleavings) from the engineering of their tools. The latter was Prior work attempts to offer integrated solutions that address
unsatisfactory; often the tools were limited to a small domain, all three aspects for a particular domain. For instance, the
hard to maintain, and hard to extend to other domains. We CHESS tool supports a subset of C# threading APIs (from the
designed Nekara, an open-source cross-platform library for easily
building custom systematic testing solutions. System.Threading namespace). Their models are build
We show that (1) Nekara can effectively encapsulate state- into the tool itself, and they are injected automatically into the
of-the-art exploration algorithms by evaluating on prior bench- program binary via binary instrumentation. This offers a seam-
marks, and (2) Nekara can be applied to a wide variety of less experience for supported programs. However, there is no
scenarios, including existing open-source systems as well as easy way to extend the tool to programs outside this supported
production distributed services of Microsoft Azure. Nekara was
easy to use, improved testing, and found multiple new bugs. class. Even C# Task-based or async-await programs, which
are very commonplace, are not supported. Furthermore, use of
I. I NTRODUCTION complex technology like binary instrumentation makes the tool
Exploiting concurrency is fundamental to building scalable hard to maintain. Other tools do not fare any better. SAMC, for
systems. It can range from desktop applications with multiple instance, only supports Sockets-based communication that
threads that exploit a multi-core CPU or giant distributed too only for ZooKeeper-like distributed systems. Supporting
systems with multiple processes spanning many VMs. In either other systems was arguably never a goal of that work.
case, getting the concurrency right is challenging. The combi- This paper aims to democratize systematic testing by al-
natorial explosion of possible interleavings between concurrent lowing users (i.e., developers) to build their own systematic
actions makes it hard to find bugs, or even reproduce known testing solutions. We propose Nekara, a cross-platform open-
ones [1], [2]. Prior work argues for systematic testing, which source library that provides a simple, yet expressive API that
hooks on to the concurrency in a program to reliably control a developer can use to model the set of concurrency primitives
the interleaving of concurrent actions, and then orchestrates that they have used in their program. Nekara encapsulates var-
a search (exhaustive or randomized) within the space of all ious search heuristics from prior work, freeing the developer
interleavings. This idea manifests in several tools, such as from having to design these themselves. Nekara can record
CHESS [2], [3] and Cuzz [4] for multi-threaded applications, scheduling decisions and provide full repro for bugs.
dBug [5], Modist [6] and SAMC [7] for distributed message- Unlike an integrated solution, Nekara delegates modeling, as
passing systems, and many others [8], [9], [10], [11], [12]. well as injection of these models, to the developer. We argue,
This paper summarizes our experience in applying system- through experience presented in this paper, that the burden on
atic testing in practice. Concurrency comes in many forms; it developers is small, and is out-weighted by many engineering
changes with the programming language (C#, Go, Rust, etc.), benefits. In most cases, applications depend on a well-defined
programming model (e.g., threads, tasks, actors, async-await, framework or library to provide concurrency support (e.g.,
etc.), framework (e.g., Service Fabric [13], libevent [14], Trio pthreads). The user can then only design models for these
[15], etc.) and so on. Our immediate learning in this space was framework APIs (only ones they used) with Nekara hooks,
that each of the tools mentioned above only address a specific and the rest of the system remains unchanged.
class of programs, and are difficult or impossible to apply to Importantly, these Nekara-enabled models are just code;
other classes of programs. they live and evolve alongside the rest of the system, and
To understand this shortcoming, we can examine the design benefit from standard engineering practices. The models can
of a typical solution. It consists of three parts. The first is be easily injected for testing, say through macros for C code ormocking utilities for higher-level languages like C#. (Binary // Resources
instrumentation is an overkill.) They can be shared between // Starting/stopping the scheduler
void wait_resource(int rid);
void attach();
multiple teams that use the same form of concurrency, or a void signal_resource(int rid);
void detach();
community can contribute to support models for a popular
framework like pthreads. Developers can even choose to // Co-operative context switch
// Operations
void schedule_next();
limit their code to only those APIs for which they have these void create_operation();
models, given the clarity that Nekara provides. void start_operation(int op);
// Nondeterministic choices
void end_operation(int op);
Nekara also helps with other forms of non-determinism as int next_integer(int min, int max);
well (such as failure injection), and provides the same benefits
of reproducibility. In all, with Nekara, systematic testing Fig. 1: Core APIs of the Nekara library.
of non-determinism is just another programming exercise,
completely in the hands of the developer.
at the end. Clearly, the assertion can fail, but only in a specific
We show the effectiveness of Nekara by documenting
interleaving where thread t1 updates the shared variable x
several case studies, each time showcasing that modeling
last. For this program, it makes sense to map threads to
concurrency requires minimal effort (less than a few weeks,
operations and locks to resources. Our goal will be to simply
easy to share) and provides significant value for testing (more
mock the concurrency-related APIs and leave the rest of the
bugs found). Nekara is just 3K lines of C++ code.1 We believe
program unchanged as much as possible.
that a solution like Nekara unlocks the potential of systematic
testing that has so far been siloed in individual tools. Figure 3 shows the mocks. The
The main contributions of this paper are as follows. create_thread_wrapper function calls
create_operation from the parent thread and then
• The design of the Nekara library that allows building
start_operation in the child thread. The former informs
custom systematic-testing solutions (Sections II and III).
Nekara that a new operation is about to be created, whereas
• Experience from several case studies that cover a range
the latter allows Nekara to take control of the child thread.
of different forms of concurrency and non-determinism
The actual thread is still spawned via create_thread;
(Sections IV to VI). Nekara has been adopted by Mi-
Nekara does not provide any runtime of its own.
crosoft Azure to test distributed services (Sections VI-A
and VI-B). Next step is to implement the synchronization via resources.
• The search algorithms in Nekara are inspired from pre-
We map each lock to a unique resource, and then acquire
vious work; we show that the generality of Nekara does and release methods can be mocked as shown in Figure 3.
not limit its bug-hunting abilities (Section VII). For ease of explanation, we have assumed that the resource
id corresponding to a lock object x is stored in the field
Section IX discusses related work and Section X concludes.
x->id, and a Boolean variable representing the status of the
II. N EKARA L IBRARY lock (locked/unlocked) is stored in the field x->acquired.
Because Nekara performs co-operative scheduling, imple-
This section illustrates how Nekara can be used to build a
menting synchronization is typically easy. The procedure
systematic testing solution. Nekara is only meant for testing.
acquire_wrapper first does a context switch to give other
Production code need not take a dependency on Nekara.
operations the chance to acquire the lock, and then goes
The core Nekara APIs are shown in Figure 1. Nekara op-
ahead to grab the lock if it is available. When the lock is
erations generalize over threads and resources generalize over
not available, then the operation blocks on the corresponding
synchronization. Operations and resources are uninterpreted,
resource. In release_wrapper, we signal the resource, so
each is just an integer. Nekara understands that each operation,
that blocked operations can try to grab the lock again. (Note
once started and before it ends, executes concurrently with
that signalling a resource unblocks all waiting operations, but
respect to other operations, unless it blocks on a resource.
Nekara ensures that only one unblocked operation executes at
Operations while executing can additionally signal a resource,
any point in time.) Any other way of implementing a lock
which unblocks all operations that may be blocked on it.
is acceptable, as long as it ensures that the only blocking
Nekara implements a co-operative scheduler (§III). It en-
operation is wait_resource.
sures that at most one operation executes at any point
in time. The current operation continues running until it The final step is to run the test in a loop for a desired number
calls schedule_next or wait_resource. At that point, of iterations, under the control of Nekara’s scheduler, as shown
Nekara can switch to execute some other enabled operation. in Figure 4. Nekara uses search heuristics to explore the
It is up to the programmer to map the concurrency in space of interleavings of the underlying test. Nekara records
their program to Nekara operations and resources. We explain the set of scheduling decisions that it makes. When a test
this exercise using the simple concurrent program shown in iteration fails, the sequence of scheduling decisions can be
Figure 2. The program contains a test case, which executes supplied back to the Nekara scheduler to directly reproduce the
the method foo using multiple threads and does an assertion buggy iteration. The default set of search heuristics in Nekara
are randomized, so we measure the effectiveness of Nekara
1 Available open source at https://github.com/microsoft/coyote-scheduler as the percentage of buggy iterations, i.e., what fraction ofModeling
Project LoC Operations Resources LoC #PW
Memcached (§IV) 21K pthread_t pthread_mutex_t, pthread_cond_t, libevent::event_loop 1K 2
Verona (§V) 8K std::thread std::condition_variable, std::atomic 302 n/a
CSCS (§VI-A) 56K Task TaskCompletionSource 3K 4
ECSS (§VI-B) 44K Task TaskCompletionSource, lock 3K 4
Coyote (§VII) 27K Actor EventQueue 16 id);
x = 0; lock = new LCK(); create_thread(starter, (op, } else {
void foo(int arg) {
// Run workload foo, args)); lock.acquired = true; break;
acquire(lock);
t1 = create_thread(&foo, 1); } }
x = arg;
t2 = create_thread(&foo, 2); }}
release(lock); void starter(int op, FUNC_PTR foo,
t3 = create_thread(&foo, 3); void release_wrapper(LCK lock) {
} ARGS_PTR args) {
// Continues in right column. scheduler.start_operation(op); assert(lock.acquired);
foo(args); lock.acquired = false;
Fig. 2: A simple concurrent program. scheduler.end_operation(op); scheduler.signal_resource(lock->id);
} }
invocations of the underlying test fail. Fig. 3: Mocks for thread creation, and lock acquire-release.
Completeness, Limitations: A natural question is if
Nekara’s exploration is complete, i.e., if it is possible to void nekara_test() {
explore all behaviors of a given test in the limit. With Nekara, Scheduler scheduler(options);
we leave this decision to the developer. Completeness can be for (int i = 0; i < 100; i++) {
scheduler.attach(); // Start the scheduler
achieved by inserting a context switch just before each non- test(); // Run the test for iteration i
commuting action [16]. For message-passing programs, non- scheduler.detach(); // Stop the scheduler
commuting actions are typically just message transfers, thus }}
instrumenting them is enough to get completeness.
In shared-memory programs, an access to shared memory Fig. 4: A typical Nekara test running for 100 iterations.
is potentially non-commuting. One option is for a developer
to implement their own methodology for inserting context
switches at memory accesses in their code. A second simpler fourth columns of Table I list what is mapped to Nekara
(and common [2]) solution is to only insert at synchronization operations and resources, respectively. The last two columns
APIs. Then the instrumentation remains limited to mocks of show the modeling effort: lines of code (LoC) as well as the
the synchronization APIs, and does not pollute the code. One number of person weeks (#PW) spent for modeling. Verona
case study (§V) uses the former strategy whereas rest use used custom Nekara modeling from the outset, so we cannot
the latter strategy. With Nekara, the aim is not necessarily quantify the effort. Each of CSCS and ECSS use the same
to find all bugs (it’s a testing solution after all), but rather to mocks, which were developed once in 4 person weeks. It is
significantly improve existing practice. Behaviors induced by worth noting that Nekara testing is an integral part of the
weak memory models [17] are also outside the scope of this engineering process for Verona, CSCS and ECSS.
paper (although interesting future work).
III. N EKARA I MPLEMENTATION
Nondeterminism: The call to next_integer returns
a randomly-generated integer within the supplied range. The The Nekara scheduler must be attached before it takes
returned value is recorded to allow for replay. This is handy for any action; once detached, all Nekara APIs are no-ops. A
modeling non-determinism such as failure injection (§VI-A) or simplified implementation of the core Nekara APIs is shown
abstracting branches (§V). in Algorithm 1. Nekara also includes APIs for joining on
Case Studies: We demonstrate Nekara on various sys- an operation, blocking on a conjunction or a disjunction of
tems (Table I). Memcached [18] is a popular open-source resources, as well as signalling a particular operation. These
in-memory key-value store with cache management. Verona additional APIs are not discussed here.
[19] is a language runtime written in C++. CSCS and ECSS Nekara must ensure that only one operation executes at
are production cloud services of Microsoft Azure, written any point in time, and it must block the rest, to give it
in C#. Coyote [20] provides a C# actor-based programming precise control of the program’s execution. Nekara maintains:
framework for building distributed systems. The third and the current operation ocur , a map M : O → R that mapsAlgorithm 1: Nekara Scheduling APIs
State: int cntpending , ocur ; M : O → R Network
1 Procedure create_operation(o)
2 O ← O ∪ {o}; M[o] ← ∅; atomic { cntpending ++ } Memcached
3 Procedure start_operation(o) Application Programming Interface (API)
4 atomic { cntpending −− } Worker Worker LRU LRU Worker Assoc
5 o.cv.wait() // cv is a condition variable Slab Rebalancer Threads Threads Crawler Maintainer Threads Maintainer
6 Procedure schedule_next()
7 while cntpending > 0 do wait() Slab
classes
8 E ← {o | M [o] = ∅} // collect enabled operations
9 if E = ∅ then raise deadlock ...
10 onxt ← S.next(E) // choose next operation ...
11 if ocur = onxt then return ... ...
12 oprev ← ocur ; ocur ← onxt Slabs LRU KV Hash Table
13 onxt .cv.notify() // resume next operation
14 if oprev ∈ E then Fig. 5: Architecture of Memcached.
15 oprev .cv.wait() // pause previous operation
16 Procedure wait_resource(r)
17 M [ocur ] ← {r}; schedule_next() Nekara captures the crux of systematic testing in a small,
18 Procedure signal_resource(r) simple C++ library. It separates search heuristics from the
19 foreach o ∈ O do
20 M [o] ← M [o] \ {r}
modeling and specialization of testing to a particular system.
IV. C ASE S TUDY: M EMCACHED
Memcached [18] (MC) is an open-source, in-memory key-
an operation to a set of resources that it’s currently blocked value store commonly used as a cache between an application
on, and a counter cntpending that is initialized to zero. An and a database. It is mostly written in C with approximately
operation o is enabled if M [o] is empty, and is disabled 21 KLOC. Being a popular multi-threaded application, it has
otherwise. Nekara creates a condition variable o.cv for each been used for benchmarking bug-detection tools in prior work
operation o that it uses to block the operation. [22], [23], [24], [25].
Calling create_operation atomically increments Figure 5 illustrates the high-level architecture of MC, show-
cntpending to keep track of operations that Nekara should ing the key data structures at the bottom and the various kinds
expect to be spawned. No other action is taken, which of threads that access them. MC maintains an in-memory,
means that the current operation ocur will continue executing. chained hash table for indexing key-value (KV) pairs. Worker
start_operation decrements cntpending and immediately threads update the hash table and the assoc maintainer thread
blocks the caller. Having these two calls decorating the spawn is responsible for expanding or shrinking the hash table when
of a new operation was important to keep Nekara independent its load crosses above or below certain threshold.
of the underlying runtime. A call to start_operation To reduce internal fragmentation, MC uses a slab-based
can happen concurrently with respect to other Nekara API. allocator for storing KV pairs. KV pairs of different sizes
The executing operation ocur continues until it calls either are mapped to different slab classes, and the slab rebalancer
schedule_next or wait_resource. The latter just calls thread redistributes memory among slab classes as needed.
the former, so we just describe schedule_next. It first For every slab class, MC maintains three linked lists, named
waits until cntpending goes to zero. (Once this happens, it hot, warm and cold LRUs, to keep track of the least recently
implies that all operations must be inside Nekara.) Nekara used (LRU) KV pairs. When a slab class runs out of memory,
then uses a search heuristic S to decide the next operation some memory is reclaimed by evicting the least recently used
to schedule from the set of all enabled operations (or raise KV pair. Two background threads, called LRU maintainer and
“Deadlock” is none is enabled). If the next operation is LRU crawler, update these linked lists and performs evictions
the same as the current, no action is necessary. Otherwise, whenever required.
the current operation is blocked and the next operation is The dispatcher thread is the main thread that starts and stops
scheduled. all other threads. Its primary function is to look for incom-
Search heuristics: Several search heuristics have been ing network connections and dispatch them to the available
proposed in prior work; Thomson et al. [12] provides a survey. worker threads, which then serve the network client’s requests.
These heuristics are based around empirical observations of MC relies on an event-driven, asynchronous model based on
where most bugs lie in practice: for instance, prioritize few libevent [14]; worker threads do not block on network I/O,
context switches [3], few delays [21], few priority-exchange but instead switch to processing another request.
points [4], [9], etc.; even selecting the next operation uniformly Integrating Nekara: We first needed to make MC
at random works well in practice [12]. Nekara, by default, has more modular and unit-testable. We mocked system calls
several heuristics implemented and uses all of them in a round- like socket, sendmsg, recvmsg, getpeername,
robin fashion (across test iterations). poll, read, write, etc. so that we could imi-Id Bug Type Description Reference
Known 1 Misuse of pthread API Double initialization of mutex and conditional variables PR#566
2 Data Race Dispatcher and worker thread race on a shared field named stats PR#573
3 Misuse of pthread API Deadlock due to recursive locking of a non-recursive mutex PR#560
4 Misuse of pthread API Deadlock due to an attempt to pthread_join a non-existing thread Issue#685
5 Atomicity Violation Two worker threads simultaneously increment the value of the same KV pair Issue#127
Null pointer dereference when one worker thread deletes a global variable
6 Atomicity violation Issue#728
while another worker thread was updating it
7 Misuse of pthread API Attempt to join a non-existant thread Issue#733
New
Slab rebalancer and the dispatcher thread deadlock due to simultaneous invocation
8 Deadlock Issue#738
of pthread_cond_signal by a worker and the dispatcher thread.
This bug can lead to either unlocking an unlocked mutex or unlocking a
9 Misuse of pthread API Issue#741
mutex that is held by some other thread (resulting in data races).
TABLE II: List of previously known bugs, as well as new bugs, that Nekara found in Memcached.
Bug#2 Bug#5 Bug#6 Bug#8
800
Uncontrolled 7 0.12% 7 7 700 Uncontrolled
Nekara 4% 20% 0.8% 0.01% Nekara
#Unique states
600
500
TABLE III: Percentage of buggy iterations, for Memcached 400
tests. Each test was executed for 10K iterations. 300
200
100
tate network traffic coming from one or multiple MC 0
1000 5000 10000 15000
clients. Nekara-specific work was limited to the mocking of #Iterations
libevent and pthread APIs. These totalled around 1
KLOC and took a nominal effort of around two weeks. Fig. 6: State coverage for Memcached.
Existing MC tests did not exercise concurrency, so we wrote
a test ourselves. It concurrently invoked several MC oper-
behaviors. We took a hash of all key data-structures of MC
ations; the workload itself was a combination of workloads
(LRU linked lists, slab classes, and the KV table) at the end
from existing tests. We then compared the response returned
of a test iteration, and counted the number of unique hashes
by MC with the expected response. Because Nekara tests run
seen over all test iterations. We ran the Nekara test for 15K
in a loop, we needed to ensure that every iteration of the test
iterations and the results are shown in Figure 6.
was independent of the previous one. This required resetting The results show a roughly four-fold increase in the total
of all the global, static variables and clearing the cache after number of hashes with Nekara, clearly indicating that it
every iteration. was able to exercise many more behaviors of MC. Deeper
Bugs: We picked five previously-known concurrency- inspection revealed that Nekara was able to trigger corner-
related bugs, listed in Table II, and injected them back in the case behaviors more often, for instance, a slab class running
latest version. We picked MC’s latest stable version, 1.6.8 for out of memory, or a get operation observing a cache miss.
experimentation. Some of these bugs (Bugs 1, 2, 5) were either Overall, our evaluation demonstrates that a system like MC
used or found by previous work [25], [23], and others were can benefit greatly from systematic testing, and using Nekara
obtained from GitHub. In the course of testing, we also found requires little effort.
four previously unknown bugs (Bugs 6 to 9), which have been
confirmed by MC developers. V. C ASE S TUDY: V ERONA
Bugs related to misuse of pthread APIs (Bug 1, 3, 4, 7, 9) Project Verona [19] is a prototype implementation of a new
were easy: they were caught in the first test iteration. The only programming language that explores the interaction between
reason they escaped MC’s existing tests is that pthreads does concurrency and ownership to guarantee race freedom. The
not fail on invalid invocations; we found them simply because runtime of the language has several complex concurrent pro-
our pthread API mocks checked for them. tocols that use shared memory. The runtime has scheduling
Table III shows results for the remaining bugs where using including work stealing, back pressure (to slow message queue
Nekara was crucial. Most of these bugs could not be caught growth), fairness, memory management using atomic reference
without Nekara despite running the test several (10K) times. counting, and global leak detection. These concepts interact in
All of previously-unknown bugs were present in MC from at subtle ways that are difficult to debug.
least the past four years, and even prior tools [23], [26] did The designers of Verona decided to use systematic testing
not find them. from the start, motivated by prior struggle with concurrency
State coverage: In addition to finding bugs, we wanted to bugs that took hours to days to resolve, and that had been a
check if Nekara indeed provides more coverage of concurrent significant barrier to making quick progress.Uncontrolled Nekara Commit Hash
Bug#1 7 0.049% 25bb324 class Task{
static Task Run(Func func); class TaskCompletionSource {
Bug#2 7 0.091% c087803
static Task Delay(TimeSpan delay); Task Task { get; }
static Task WhenAll(params ...
TABLE IV: Percentage of buggy iterations, for Verona tests. Task[] tasks); void SetResult(T result);
Each test was executed repeatedly for 5 mins. static Task WhenAny( void SetException(Exception ex);
params Task[] tasks); void SetCanceled(
... CancellationToken ct);
TaskAwaiter GetAwaiter(); }
During development of the Verona runtime, the scheduler, }
concurrent queues, and memory management protocols were
carefully reviewed for uses of shared memory concurrency. Fig. 7: Task and TaskCompletionSource APIs.
Threads were mapped to operations (like in Section II).
Synchronization happened in two forms. The first was the use
of std:atomic; these remain unchanged except that before VI. C ASE S TUDY: TASK PARALLEL L IBRARY
every store, and after every load, a call to schedule_next
is inserted, because they mark a potentially racy access to The Task Parallel Library [27] (TPL) is a popular, open-
shared memory. The second was the use of condition variables; source, cross-platform library provided by .NET for building
these directly map to Nekara resources. concurrent applications. TPL exposes several key types, such
Verona uses Nekara’s next_integer to control other as Task and TaskCompletionSource that interoper-
sources of non-determinism. For instance, object identity, in ate with the async and await keywords in the C# language,
systematic testing builds, was made deterministic, so features enabling writing asynchronous code without the complexity of
that sort based on identity can be tested reproducibly. The managing callbacks. A developer writes code using these high-
runtime has numerous heuristics to postpone expensive op- level APIs and TPL takes care of the hard job of partitioning
erations until there is sufficient work to justify their cost. the work, scheduling tasks to execute on the thread pool,
This implies that certain bugs, which require the expensive canceling and timing out tasks, managing state and invoking
operation to execute, can take a long time to manifest. The asynchronous callbacks.
postponement-heuristic was replaced with systematic choice, TPL is pervasive in the .NET ecosystem. We designed
i.e., if next_integer(0,1) == 0. This had two ben- TPLN as a drop-in-replacement library for TPL. TPLN pro-
efits: (1) it shortened the trace length to find a bug, and (2) it vides stubs that replace the original TPL APIs, as well as
removed any dependency on a specific heuristic’s behaviour. subclasses that override original TPL types. These stubs and
Verona uses systematic testing as part of its code-review subclasses call into Nekara via a C++ to C# foreign-function
and CI process. Any change to the Verona runtime has an interface. Any C# application that uses TPL for its concurrency
additional twenty minutes of CI time for running systematic simply needs to replace it with TPLN to get systematic testing.
testing. There is a small amount of stress testing, but most We now explain core TPLN design.
runtime bugs are found using systematic testing. The project’s The Task type (Figure 7) provides several public-facing
ethos is such that any failure found which did not exhibit APIs including: Task.Run for queueing a function to execute
during systematic testing is treated as two bugs: the underlying on the thread pool and returning a task that can be used
bug, and a bug in the use of systematic testing. The latter as a handle to asynchronously await for the function to
is fixed first by writing a systematic test that reveals the complete; Task.WhenAll and Task.WhenAny for waiting
bug. Moreover, users of Verona get systematic testing for free one or more tasks to complete; Task.Delay for creating
because the runtime is already instrumented with Nekara. an awaitable task that completes after some time passes; and
Anecdotal evidence from the Verona team has said that the compiler-only APIs, such as Task.GetAwaiter, which
use of systematic testing has given greater confidence for new the C# compiler uses in conjunction with the async and
members of the team to modify the runtime primarily due await keywords to generate state machines that manage
to the debugging experience of replayable crashes. Detailed asynchronous callbacks [28].
logging and replayable crashes provide a way to understand Figure 8 shows the Nekara-instrumented version of
the subtle interactions in concurrent systems that would nor- Task.Run. For simplicity, we have omitted low-level de-
mally be a significant barrier to entry for new programmers. tails such as task cancellation and exception handling.
Most runtime bugs do not make it off the developer’s machine Task.Run of TPLN creates a new Nekara operation
as the local systematic testing catches them before CI. Two via create_operation, and then invokes the origi-
recent bugs that we investigated are listed in Table IV. Both nal Task.Run to spawn a task. This new task first
bugs would not have been found without systematic testing. calls start_operation, then invokes the user func-
Bug #1 was a failure to correctly protect memory from tion, followed by end_operation. The parent task calls
being deallocated by another thread. The window for this to schedule_next to give the child task a chance to execute.
occur was a few hundred cycles, hence almost impossible to TaskCompletionSource (TCS), shown in Fig-
reproduce reliably without systematic testing. The second bug ure 7, allows developers to asynchronously produce and con-
was due to not considering a corner case of a new feature. sume results. This type exposes a Task get-only propertyusing SystemTask = System.Threading.Tasks.Task;
static Task Run(Func func) { (Mock) Client
// Create a new Nekara operation id for the new task.
int op = GetUniqueOperationId(); CSCS Kubernetes Cluster
Nekara.create_operation(op);
var task = SystemTask.Run(async () => { Control Plane Data Plane Worker
ASP.NET ASP.NET ASP.NET
Nekara.start_operation(op); Microservice Microservice Microservice
// Execute the user-specified asynchronous function.
// The await logic is instrumented with Nekara.
await func();
Nekara.end_operation(op);
});
(Mock) Storage Queue (Mock)
Nekara.schedule_next(); Cosmos DB
return task;
} Fig. 10: The high-level architecture of CSCS.
Fig. 8: Instrumentation of Task.Run with Nekara.
completed result.
// TCS context used for Nekara testing. Task Task => { We also modeled two other TPL types. First is the
class TCSContext { // Get the current TCS context. Monitor type that implements a reentrant lock in C#
// Nekara resource id for the TCS. var context = GetCurrentContext();
int Id = GetUniqueResourceId(); if (context.IsCompleted) {
(along similar lines to Figure 3). Second is the type
// The result set by the TCS. // If TCS is completed, return the result. AsyncTaskMethodBuilder that the C# compiler uses to
T Result = default; return Task.FromResult(context.Result);
bool IsCompleted = false; }
generate state machines to manage asynchronous callbacks in
} methods that use async and await.
void SetResult(T result) { // Return a Nekara-controlled task Creating TPLN took roughly one person month, with most
var context = GetCurrentContext(); // that will be completed by the producer.
if (!context.IsCompleted) { return Task.Run(() => { time spent in ensuring that we support each TPL API and
// Set the TCS result. // Wait the producer to set the result. maintain details such as exception propagation, cancellation,
context.Result = result; Nekara.wait_resource(context.Id);
// Exception/cancellation logic. etc. This is largely a one-time effort (unless TPL itself changes
context.IsCompleted = true;
// Signal the TCS consumer. ... significantly). Several engineering teams in Microsoft were
Nekara.signal_resource(context.Id); return context.Result;
}); able to use TPLN to test their services without needing
}
} }; any changes to their production code. Two such systems
are summarized next in Sections VI-A and VI-B. They use
Fig. 9: Instrumentation of TCS APIs with Nekara. conditional compilation to automatically replace the original
TPL library with TPLN during testing.
that a consumer can await to receive a result of type T asyn- A. Testing CSCS with TPLN
chronously. This task remains uncompleted until the producer Cloud Supply Chain Service (CSCS) exposes a set of
completes it with a result by invoking SetResult. HTTP REST APIs that clients can invoke to create supply-
Instrumentation of TCS Task and SetResult is shown in chain entities and orchestrate supply-chain processes. CSCS
Figure 9. We designed TCSContext, a simple test-only is designed with a typical microservice-based architecture
data structure in TPLN that contains information needed to (Figure 10) where multiple stateless microservices coordinate
model a TCS. TCSContext contains a Nekara resource with each other through shared state maintained in backend
id associated with the TCS, the result of the TCS, and a storage systems. CSCS consists of roughly 56K lines of C#
Boolean value that is set to true once the TCS completes. code. It is built using ASP.NET [29] and achieves horizontal
TCSContext is set to the TCS state upon initialization scalability through Kubernetes [30].
by TPLN , so that it can be accessed when invoking one of the The CSCS microservices, although stateless, concurrently
stub TCS APIs. The producer (SetResult) is modeled as access the backend storage, including Cosmos DB [31] (a
follows: it first accesses the context, then checks if the TCS has globally-distributed database service) and Azure Queue Stor-
completed and, if not, it sets the result and IsCompleted age [32] (a durable distributed queue). Some requests in
to true and signals the resource associated with the TCS CSCS follow a simple request/response pattern, while others
to unblock any task that might be waiting on the TCS Task trigger background jobs, making the client periodically poll
getter property. The consumer (Task getter) is modeled as to check on the completion of the job. This requires complex
follows: it first accesses the context, then checks if the TCS synchronization logic between the microservices.
has completed and, if it has, it simply returns a completed task CSCS is written against storage interfaces, so they can
with the result. If the TCS has not completed yet, it will create be easily mocked during testing using techniques such as
a new task by invoking the Task.Run TPLN API (which we dependency injection. Multiple concurrent client calls are sim-
described above). This asynchronous task immediately waits ulated by spawning concurrent tasks that invoke the relevant
on the resource, and once the producer signals, it returns the ASP.NET controller actions.// Instantiates a Cosmos DB Mock, an instance of a CSCS cancel and reject an entity at the same time, Nekara uncovered
// ASP.NET microservice, and a CSCS client. an issue where the system got into an inconsistent state. This
var cosmosDbMock = new CosmosDb_Mock(...); bug had escaped stress testing and manual code review.
var factory = new ServiceFactory(cosmosDbMock, ...); c) Resource creation liveness issue (Bug#3): Certain
var client = factory.CreateClient(...);
requests trigger a background task requiring the client to peri-
// Invokes a concurrent Create and Update client request. odically poll its completion. This functionality is implemented
Task req1 = Task.Run(() => client.Create("id", by storing a record indicating the request status in Cosmos DB
{ Content: "payload1", Timestamp: 7 })); and then submitting the job to a worker queue to trigger the
Task req2 = Task.Run(() => client.Update("id",
asynchronous work. There was a bug where the submission to
{ Content: "payload2", Timestamp: 8 }));
the worker queue could fail due to network connectivity issues.
await Task.WhenAll(req1, req2); However, as the record was created in the database, the user
would find the status to be pending-creation upon a
// Gets the resource (stored in Cosmos DB) and asserts GET request and would erroneously assume the resource will
// it contains the expected payload and timestamp.
var resource = await client.Get("id"); be eventually created. This liveness bug was caught with a test
Assert.IsTrue(resource.Content == "payload2" && that simulated potential network failures.
resource.Timestamp == 8); d) Race condition in test logic (Bug#4): Interestingly,
Nekara found a bug in the CSCS test code itself. The buggy
Fig. 11: A simple Nekara concurrent test in CSCS. test performed two concurrent PUT requests to provision a
resource, then waited for the provisioning to complete and
Bug#1 Bug#2 Bug#3 Bug#4 then deleted the resource. The test was failing because two
Uncontrolled 7 7 7 7 concurrent Create requests led to two asynchronous workers
Nekara 11% 7% 1% 1% for the same resource. The test then deleted the resource as
soon as one of the workers transitioned the resource state to
TABLE V: Percentage of buggy iterations on CSCS tests. created. However, there was a race between the second
asynchronous worker and the Delete request, which caused
the test to fail. The developers were initially not sure if this
CSCS concurrency unit tests range from simple concurrency bug was in their production logic or test logic, but due to
patterns where the test calls an API with different inputs but Nekara’s reproducible traces they were able to understand the
the same key (to exercise interference in Cosmos DB) to more issue and fix it.
complex tests that randomly fail certain mock invocations
(using the next_integer API) to simulate intermittent B. Testing ECSS with TPLN
network failures. Figure 11 shows a simple CSCS test. These Cloud storage uses geo-redundancy to protect against catas-
tests, when exercised by Nekara, were able to uncover subtle trophic data center failures. The Erasure Coding Storage Ser-
bugs. Table V lists some of the bugs, comparing testing with vice (ECSS) offers an economical solution to this problem by
and without Nekara. Each test was run multiple times for a applying erasure coding to blob objects across geographically
total of 5 minutes and the table shows percentage of buggy distributed regions. Figure 12 shows a partial view of the
runs. Without Nekara, none of these bugs would have been high-level architecture of ECSS. The system consists of a data
found. Following is a description of these bugs. service and a metadata service. The data service is responsible
a) Data loss due to concurrent requests (Bug#1): CSCS for striping data and generating parities across regions, as well
requires that upon two concurrent Create or Update re- as reconstructing data in the event of failures. The metadata
quests, only the request with the latest modified timestamp service manages erasure coding stripes and handles dynamic
succeeds. To achieve this, CSCS uses Cosmos DB ETags updates to the stripes (due to object creation, update, and
functionality for optimistic concurrency control, but a bug deletion). ECSS consists of roughly 44K lines of C# code.
in the handling of ETags led to a stale Create overwriting To achieve high-throughput, ECSS was designed to be
fresher data. This bug was missed by both stress testing and highly-concurrent. The data service implements a component
manual code review, but found quickly with Nekara (with the called Syncer that periodically synchronizes metadata between
test shown in Figure 11). This bug could have lead to customer individual regions and the metadata service using Azure
data loss. Queue Storage. Syncer is sharded and the ECSS developers
b) Inconsistent entity state (Bug#2): CSCS manages two implemented a lease-based mechanism to assign different
sets of related entities, which are stored in different tables and Syncer partitions to different metadata service nodes. The
partitions of Cosmos DB. Rejecting an update on one of the metadata service executes two long running TPL tasks: a
entities, must lead to rejection of updating the other entity too. table updater and a table scanner. The updater asynchronously
However, Cosmos DB does not support transactions between dequeues Syncer messages from Azure Queue Storage and
entities stored in different partitions, and the developers had uses their contents to update Azure Table Storage. The scanner
to implement custom synchronization logic to get around this periodically scans Azure Table Storage to check different types
limitation. When the team wrote a concurrent test that tries to of metadata. Based on the metadata state, the scanner willTPLN CoyoteN Coyote
Metadata Service
Benchmarks BI% Time BI% Time BI% Time
In-memory Action Queue
` ... Ch. Replication 7 594 0.01% 197 0.01% 224
Data Service Fail. Detector 7 39 0.08% 19 0.07% 23
In-memory Action Queue
Action Paxos 0.05% 254 0.07% 56 0.06% 104
Data Block
Engine
Raft 0.35% 789 0.29% 151 0.38% 156
... Syncer Table Scanner Table Updater
TABLE VI: Comparing systematic testing with Nekara against
the original Coyote. Tests run for 10k iterations. BI% denotes
percentage of buggy iterations. Time is in seconds.
(Mock) Storage Table
(Mock) Storage Queue
metadata and enqueues this message to Azure Queue Storage.
Fig. 12: Parts of the high-level architecture of ECSS. Next, Syncer_2 continues executing and generates msg B
containing version 3 of the metadata and also enqueues this
message. Finally, the metadata service dequeues conflicting
init and read
metadata from v1 read messages from the same partition, which could result in a
Syncer_1 data at
update later version of the metadata being overwritten by an outdated
time 2 enqueue
metadata
msg_A
to v2 version. To fix the bug, the developers had to write logic just
(Mock) Storage Queue before enqueueing the messages to check if the metadata and
(Mock) Data Block 1. msg_A (metadata_v2)
Storage Table 2. msg_B (metadata_v3)
the version are consistent, and if not then discard the message.
update
This bug had escaped continuous unit and stress tests.
enqueue
metadata
read msg_B
Nekara was able to find it in under 10 seconds and just 8
to v3
Syncer_2
init and read
data at test runs (on average). The ECSS team (as well as the CSCS
time 1
metadata from v2 team) routinely run Nekara tests as part of their CI.
Fig. 13: Race condition in the ECSS data service.
VII. R EPRODUCING K NOWN B UGS
We evaluate Nekara against three prior tools on their own
enqueue actions on a set of in-memory queues. Long-running set of benchmarks. The purpose of this evaluation is to show
tasks execute action engines that drain these queues, perform that one can get state-of-the-art systematic testing with Nekara.
actions on the state and update the metadata in Azure Table a) Coyote: The first comparison is against Coyote [20]
Storage, as well as sending action messages to the data service that provides an open-source .NET actor library, used by teams
through Azure Queue Storage to do erasure coding among in Azure [33]. Coyote provides a runtime for executing actors.
other operations. All actors execute concurrently and communicate by sending
Eventually, the state of the data service and Azure Ta- messages to each other. Coyote also provides a systematic
ble Storage must be consistent. ECSS manages exabytes of testing solution for testing these actor-based programs [11],
customer data, and correctness is absolutely vital, which is [34].
why the team used TPLN for thorough testing. No changes We directly instrumented the Coyote runtime using Nekara
were required to the production code. The main investment to build our own systematic testing solution. We had two
was in writing the tests: the tests instantiate the Syncer and options. In the first approach, we took advantage of the Coyote
the metadata service in-memory, use dependency injection for runtime being implemented entirely on top of TPL, which
inserting their mocks of Azure Table Storage and Azure Queue we simply replaced with TPLN . In the second approach, we
Storage, write input data and finally assert that the Azure Table instead instrumented at the level of actor semantics: an actor
Storage state is consistent. is mapped to an operation, and the actor’s inbox is mapped
Nekara helped find several critical bugs that could have to a resource. We skip the details of this instrumentation for
resulted in data loss. Figure 13 illustrates one of these bugs, lack of space; the high-level summary is that it only required
a race condition between two Syncer instances from the same 16 lines of changes to the Coyote runtime. We refer to the
partition. The first Syncer instance (Syncer_1) starts and second approach as CoyoteN . Note that in both approaches, all
reads metadata with version 1 from Azure Table Storage, changes were limited to the Coyote runtime; the user program
updates it and writes it back to the table with version 2. remains unchanged.
On the same partition, a new Syncer instance (Syncer_2) Table VI shows results on prior Coyote benchmarks, which
starts, reads the same metadata (which now has version 2), consist of buggy protocol implementations. The two Nekara
and updates it to version 3. Immediately after, Syncer_2 approaches have different advantages. TPLN has the benefit of
reads from the data block, but just before it continues its being able to test the Coyote runtime itself (that it correctly
execution, Syncer_1 reads the latest data from the same implements actor semantics). Moreover, the instrumentation
block and generates msg A containing version 2 of the was mechanical and required no knowledge of Coyote itself.Nekara
class MockDictionary : Dictionary {
int SharedVar; bool IsWrite = false; ... Applications LoC #BF BR? BI%
void override Add(K key, V value) {
bool override ContainsKey(K key) { 3
var tid = Task.CurrentId; DataTimeExtention 3.2K 3 89.3%
var tid = Task.CurrentId;
SharedVar = tid; IsWrite = true; FluentAssertion 78.3K 2 3 51.3%
SharedVar = tid;
TSVD
Nekara.schedule_next(); K8s-client 332.3K 1 3 11.7%
Nekara.schedule_next(); // Check for race.
// Check for race. Radical 96.9K 3 3 28.3%
assert(SharedVar == tid);
assert(!(SharedVar != tid && IsWrite)); System.Linq.Dynamic 1.2K 1 3 99.0%
IsWrite = false;
return base.ContainsKey(key); Thunderstruck 1.1K 2 3 48.3%
base.Add(key, value);
}
} SpiderMonkey∗ 200K 2 3 0.5%
}
Maple
Memcached-1.4.4 10K 1 3 20.0%
Fig. 14: Mock dictionary instrumented to detect races. StreamCluster∗ 2.5K 3 3 41.7%
Pbzip2 1.5K 1 3 50.0%
TABLE VII: Comparison with TSVD and Maple. #BF is
However, bugs in the Coyote runtime was not in question number of bugs found by these tools. The 3(under BR?)
here, and we found this approach to have worse performance denotes that Nekara reproduced all these previously found
than the other systematic testing solutions. Instrumenting at bugs. BI% denotes percentage of buggy iterations.
the TPL level significantly increased the number of operations
and scheduling points in the program, which decreased bug-
finding ability and increased test time. CoyoteN , however, was Cluster (online clustering of input streams), and pbzip2 (a
comparable to Coyote because both directly leverage actor parallel implementation of bzip2). Bugs in these applications
semantics. We also compared against uncontrolled testing, include atomicity violations, order-violation, deadlocks and
which unsurprisingly, could not find any of the bugs. livelocks. All these benchmarks use pthreads so we reused
We make a note on the relationship of Coyote to Nekara the models from Section IV. Table VII shows the results.
because both projects have influenced each other. Coyote had Nekara found all the reported bugs; most in a small number
earlier only supported an actor-based programming model. of iterations. These numbers are either comparable or smaller
Nekara inherited many of the search techniques used in than those reported by Maple, although a direct comparison
Coyote, but applied them to a generalized setting. Given is not possible because of the different set of techniques and
the success of Nekara’s TPLN model in testing Task-based instrumentation used. For some benchmarks, marked in the
programs, the Coyote team has since incorporated that work table with a ∗ , we also inserted schedule_next just before
natively to support Task-based programs as well. Coyote global variables accesses, without which we were unable
uses bytecode-level instrumentation to automatically inject to find some of the bugs (due to the incompleteness issue
hooks into an unmodified C# program, making the end-user mentioned in Section II).
experience more seamless than with using TPLN . VIII. E XPERIENCE S UMMARY
b) TSVD: In the second experiment, we reproduce bugs This section summarizes our experience in integration
found by TSVD [35], a tool that looks for thread-safety viola- Nekara with the various case studies presented in this paper.
tions (TSVs), which are concurrent invocations of operations Integration: We were able to integrate Nekara testing
on a non-thread-safe data structure (e.g., a Dictionary). with several systems with no changes to the production code in
TSVD’s open-source evaluation [35] covered nine .NET appli- most cases. Only in the case of Memcached, we had to modify
cations; here we consider six of those (one was removed from the code in order to mock system calls to sockets so that we
GitHub and in two others we were unable to locate a TSV bug could write unit tests with multiple concurrent clients. The fact
from the cited GitHub issue). In each application, we replaced that production code need not take a dependency on Nekara
TPL with TPLN and made one additional change. To capture was important was acceptance with development teams.
TSV as an assertion, we implemented a MockDictionary Modeling effort: Table I shows that the modeling effort
type as a subclass of Dictionary, and modified the applica- was small to moderate. For systems like Verona, systematic
tion to use this type. Figure 14 shows this mock: an assertion testing was always an integral part of its development process.
failure in the mock corresponds to a TSV. Table VII shows Systems like ECSS and CSCS fully shared their models
the results: we were able to find all TSVs, taking at most 8 (TPLN ) demonstrating amortization of effort across teams.
iterations on average. In the DataTimeExtension benchmark, Development of the models does require some expertise in
we found four additional TSVs (not reported by TSVD) by reasoning about concurrency, especially for understanding the
running the test for 100 iterations. semantics of synchronization APIs and encoding it correctly
c) Maple: The third comparison is against Maple [36], a using Nekara resources. Correctness of these models is a
systematic-testing tool that uses dynamic instrumentation and concern, because mistakes can lead to deadlocks when running
provides coverage-driven testing through online profiling and Nekara tests. We leave the problem of validating models as
dynamic analyses. We picked a set of real-world benchmarks future work. In general, it would be interesting to explore a
from SCTBench [12]. These include: an older version of Mem- community-driven effort that maintains models of common
cached, SpiderMonkey (a JavaScript runtime engine), Stream- concurrency frameworks or APIs.Bugs: Nekara helped catch several bugs, including live- were potentially racy accesses. Data race detection typically
ness bugs, deadlocks, memory leaks as well as functionality requires monitoring memory accesses at runtime. Nekara can
bugs like data corruption. Many of these would not have been help generate a diverse set of concurrent executions for these
caught with existing practices like stress testing or code review. tools, or be used directly for specific races (§VII).
Writing test cases: Developing good tests that exercise Another related problem is deterministic replay of pro-
concurrency in the system, and assert something meaningful, cesses, even virtual machines [48], [49], [50], [51], [52]. These
are crucial to get benefits from systematic testing. For Mem- techniques seek generality to support arbitrary systems, and
cached, we wrote a generic test by simply combining existing require very detailed tracing. The problem is simpler in our
test cases. For other systems, the developers of those systems setting, as we are focussed on a single test written by a
were able to write tests themselves without our help. developer aware of the concurrency used in their application.
Debugging: Repro capabilities of Nekara was well ap-
preciated by developers. Furthermore, instrumentation of a X. C ONCLUSIONS
runtime (like Verona or Coyote) provides systematic testing
Systematic testing holds promise in changing the way we
to users of the runtime for free.
test concurrent systems. In this paper, we present Nekara,
IX. R ELATED W ORK a simple library that allows developers to build their own
systematic testing solutions. Integration of Nekara is a simple
The systematic testing approach has its roots in stateless
programming exercise that only requires modeling of key
model checking, popularized first by VeriSoft [10]. Stateful
concurrency APIs. The model code is easy to share to further
approaches require capturing the entire state of a program in
amortize the cost across multiple projects. We report several
order to avoid visiting the same state again, because of which
case studies where the use of Nekara made considerable
these techniques are typically applied on an abstract model
impact, both in existing systems, as well as systems designed
of an implementation [37], [38]. Stateless approaches, on the
from scratch with systematic testing.
other hand, only control program actions. They do not inspect
program state at all, consequently are directly applicable to R EFERENCES
testing the implementation itself. All these techniques were
initially focussed on verification. CHESS [39] shifted the [1] J. Gray, “Why do computers stop and what can be done about it?” in
Proceedings of the 5th Symposium on Reliability in Distributed Software
focus to bug finding; it prioritized exploration of a subset and Database Systems. IEEE, 1986, pp. 3–12.
of behaviors, one with a few number of context switches, [2] M. Musuvathi, S. Qadeer, T. Ball, G. Basler, P. A. Nainar, and
and found many bugs. Several randomized search techniques I. Neamtiu, “Finding and reproducing heisenbugs in concurrent pro-
grams,” in Proceedings of the 8th USENIX Symposium on Operating
[4], [9], [12], [40], [21] have followed since, showcasing very Systems Design and Implementation, 2008, pp. 267–280.
effective bug-finding abilities. Our focus has been on making [3] M. Musuvathi and S. Qadeer, “Fair stateless model checking,” in
systematic testing easy to use, to that end we capture all Proceedings of the ACM SIGPLAN 2008 Conference on Programming
Language Design and Implementation, Tucson, AZ, USA, June 7-13,
these search techniques inside Nekara. One class of techniques 2008, R. Gupta and S. P. Amarasinghe, Eds. ACM, 2008, pp.
that we are unable to capture in Nekara’s interface currently 362–371. [Online]. Available: https://doi.org/10.1145/1375581.1375625
is partial-order-reduction (POR) based techniques [10], [41]. [4] S. Burckhardt, P. Kothari, M. Musuvathi, and S. Nagarakatte, “A
POR requires knowing if the next steps of two different randomized scheduler with probabilistic guarantees of finding bugs,”
in Proceedings of the 15th International Conference on Architectural
operations are independent of each other or not. Supporting Support for Programming Languages and Operating Systems, ASPLOS
POR require more information to be supplied to Nekara, which 2010, Pittsburgh, Pennsylvania, USA, March 13-17, 2010, 2010, pp.
is interesting future work. 167–178. [Online]. Available: https://doi.org/10.1145/1736020.1736040
[5] J. Simsa, R. Bryant, and G. A. Gibson, “dbug: Systematic
Instantiation of systematic testing exists for multi-threaded testing of unmodified distributed and multi-threaded systems,” in
[42], [2], [3], [4], [41] as well as message-passing programs Model Checking Software - 18th International SPIN Workshop,
[5], [6], [7], [8], [9], however their combined reach is still Snowbird, UT, USA, July 14-15, 2011. Proceedings, ser. Lecture
Notes in Computer Science, A. Groce and M. Musuvathi, Eds.,
small. For instance, most C# applications that we considered vol. 6823. Springer, 2011, pp. 188–193. [Online]. Available:
are built on TPL Tasks. These Tasks eventually execute on https://doi.org/10.1007/978-3-642-22306-8\ 14
the .NET threadpool, so one can consider them to be multi- [6] J. Yang, T. Chen, M. Wu, Z. Xu, X. Liu, H. Lin, M. Yang, F. Long,
L. Zhang, and L. Zhou, “MODIST: transparent model checking of
threaded applications, but instrumenting the .NET runtime is unmodified distributed systems,” in Proceedings of the 6th USENIX
challenging, and we did not find any readily applicable tool. Symposium on Networked Systems Design and Implementation, 2009,
Moreover, even if this was possible, instrumenting at a higher- pp. 213–228.
[7] T. Leesatapornwongsa, M. Hao, P. Joshi, J. F. Lukman, and H. S.
level is typically much easier (§VI) and more efficient (§VII). Gunawi, “SAMC: semantic-aware model checking for fast discovery
Our goal is to unlock systematic testing; modeling is not of deep bugs in cloud systems,” in Proceedings of the 11th USENIX
hidden inside a tool, but available as code that can be readily Symposium on Operating Systems Design and Implementation, 2014,
pp. 399–414.
adopted by others. [8] J. F. Lukman, H. Ke, C. A. Stuardo, R. O. Suminto, D. H. Kurni-
Complementary to systematic testing is the work on finding awan, D. Simon, S. Priambada, C. Tian, F. Ye, T. Leesatapornwongsa,
low-level concurrency bugs such as data races and atomic- A. Gupta, S. Lu, and H. S. Gunawi, “Flymc: Highly scalable testing
of complex interleavings in distributed systems,” in Proceedings of the
ity violations [43], [44], [45], [46], [47]. These techniques Fourteenth EuroSys Conference 2019, Dresden, Germany, March 25-28,
examine a given concurrent execution and evaluate if there 2019, 2019, pp. 20:1–20:16.You can also read
