G-Thread is a lock-free software-only runtime system for C++ that eliminates concurrency errors for fork-join parallel programs. G-Thread reimplements a subset of the system called [Grace] (https://dl.acm.org/citation.cfm?doid=1640089.1640096).
By including the header file and linking against the G-Thread library, your pthread programs are easily free of concurrency errors such as atomicity violation, order violation, race conditions, etc.
To adapt your pthread program to use G-Thread is simple:
-
Include the library
#include "libgthread.hh" -
Copy over your program into src/ directory and run
make -
Inside
src/directory, run./gtest
test.cc is an example program that illustrates the elimination of
race condition using G-Thread. Other examples can be found in
example folder or you can easily adapt problematic programs in pthread folder to use gthread by including libgthread.hh.
To run this test:
cd src/
cp ../example/test.cc ./
make clean all
./src/gtest
To print out the logging information while G-Thread is running, uncomment this line
to define LOGPRINT macro and recompile the program.
Those are some of the limitations that G-Thread currently has:
-
G-Thread only supports fork-join parallelism and does not support programs with concurrency control through synchronization primitives such as condition variables.
-
Although stack and heap memory will work without any concurrency issues, the global variable still need to be protected by locks or other synchronization control to avoid concurrency bugs.
-
I/O (e.g. printing to the console or writing to a file) within each thread can happen multiple times if that particular thread is rolled back due to a conflict with other thread.
-
No memory used by user's program or G-Thread will ever be reclaimed by OS even if user explicitly called
free. -
Return value from the thread isn't supported yet.
-
Only heap-allocated memory can be passed into threads without concurrency issues. Stack-allocated variables passed into threads are not supported at this moment.
G-Thread is able to sacrifice some performance to guarantee sequential semantics
of the program. You can comment out this line
to not define NO_ORDER macro and recompile the program to let the program be free of
order violation. See order_violation.cc for illustration of order violation.