Note that we also provide a series of benchmarks (distributed separately),
-which can be placed under the benchmarks/ directory. After building CDSChecker,
+which can be placed under the `benchmarks/` directory. After building CDSChecker,
you can build and run the benchmarks as follows:
cd benchmarks
make
./run.sh barrier/barrier -y -m 2 # runs barrier test with fairness/memory liveness
- ./bench.sh # run all benchmarks twice, with timing results
+ ./bench.sh # run all benchmarks and provide timing results
Running your own code
---------------------
-We provide several test and sample programs under the test/ directory, which
+We provide several test and sample programs under the `test/` directory, which
should compile and run with no trouble. Of course, you likely want to test your
own code. To do so, you need to perform a few steps.
* Action type: The type of operation performed
- * MO: The memory-order for this operation (i.e., `memory_order_XXX`, where XXX is
- relaxed, release, acquire, rel_acq, or seq_cst)
+ * MO: The memory-order for this operation (i.e., `memory_order_XXX`, where `XXX` is
+ `relaxed`, `release`, `acquire`, `rel_acq`, or `seq_cst`)
* Location: The memory location on which this operation is operating. This is
well-defined for atomic write/read/RMW, but other operations are subject to
* Value: For reads/writes/RMW, the value returned by the operation. Note that
for RMW, this is the value that is *read*, not the value that was *written*.
For other operations, 'value' may have some CDSChecker-internal meaning, or
- it may simply be a don't-care (such as 0xdeadbeef).
+ it may simply be a don't-care (such as `0xdeadbeef`).
* Rf: For reads, the sequence number of the operation from which it reads.
[Note: If the execution is a partial, infeasible trace (labeled INFEASIBLE),