The qthreads API is designed to make using large numbers of threads convenient and easy. The API maps well to both MTA-style threading and PIM-style threading, and is still quite useful in a standard SMP context. The qthreads API also provides access to full/empty-bit (FEB) semantics, where every word of memory can be marked either full or empty, and a thread can wait for any word to attain either state.
The qthreads library on an SMP is essentially a library for spawning and controlling coroutines: threads with small (4-8k) stacks. The threads are entirely in user-space and use their locked/unlocked status as part of their scheduling.
The library's metaphor is that there are many qthreads and several "shepherds". Shepherds generally map to specific processors or memory regions, but this is not an explicit part of the API. Qthreads are assigned to specific shepherds and do not generally migrate.
The API includes utility functions for making threaded loops, sorting, and similar operations convenient.
Need help or interested in finding out more? Join us on our Slack channel: https://join.slack.com/t/qthreads/signup
On a machine with approximately 2GB of RAM, this library was able to spawn and handle 350,000 qthreads. With some modifications (mostly in stack-size), it was able to handle 1,000,000 qthreads. It may be able to do more, but swapping will become an issue, and you may start to run out of address space.
This library has been tested, and runs well, on a 64-bit machine. It is occasionally tested on 32-bit machines, and has even been tested under Cygwin.
Currently, the only real limiting factor on the number of threads is the amount of memory and address space you have available. For more than 2^32 threads, the thread_id value will need to be made larger (or eliminated, as it is not required for correct operation by the library itself).
For information on how to use qthread or qalloc, there is A LOT of information in the header files (qthread.h and qalloc.h), but the primary documentation is man pages.
The most important functions in futurelib that a person is going to use are mt_loop and mt_loop_returns. The mt_loop function is for parallel iterations that do not return values, and the mt_loop_returns function is for parallel iterations that DO return values. The distinction is not always so obvious.
mt_loop is used in a format like so:
mt_loop<...argtypelist..., looptype>
(function, ...arglist..., startval, stopval, stepval);
The "stepval" is optional, and defaults to 1.
Essentially what you're doing is in the template setup (in the <>) you're specifying how to handle the arguments to the parallel functions and what kind of parallelism you want. Options for 'looptype' (i.e. the kind of parallelism) are:
mt_loop_traits::Par - fork all iterations, wait for them to finish
mt_loop_traits::ParNoJoin - same as Par, but without the waiting
mt_loop_traits::Future - a resource-constrained version of par, will limit
the number of threads running at a given time
mt_loop_traits::FutureNoJoin - same as Future, but without waiting for
threads to finish
The argtypelist is a list of conceptual types defining how the arguments to the parallel function will be handled. Use one conceptual type per argument, in the order the arguments will be passed. Valid conceptual types are:
Iterator - The parallel function will be called with the current loop
iteration number passed into this argument.
ArrayPtr - The corresponding argument is a pointer to an array, and each
iteration will be passed the value of array[iteration]
Ref - The corresponding argument will be passed as a reference.
Val - The corresponding argument will be passed as a constant value
(i.e. the same value will be passed to all iterations)
For example, doing this:
for (int i = 0; i < 10; i++) {
array[i] = i;
}
Would be achieved like so:
void assign(int &array_value, const int i) {
array_value = i;
}
mt_loop<ArrayPtr, Iterator, mt_loop_traits::Par>
(assign, array, 0, 0, 10);
The mt_loop_returns variant adds the specification of what to do with the
return values. The pattern is like this:
mt_loop_returns<returnvaltype, ...argtypelist..., looptype>
(retval, function, ...args..., start, stop, step);
The only difference is in the returnvaltype and the retval. The returnvaltype can be either an ArrayPtr or a Collect. If it is an ArrayPtr, the loop will behave similar to the following loop:
for (int i = start; i < stop; i += step) {
retval[i] = function(args);
}
Each return value will be stored in a separate entry in the retval array. The Collect type is more interesting, and can be either:
Collect<mt_loop_traits::Add> - this sums all of the return values in
parallel
Collect<mt_loop_traits::Sub> - this subtracts all of the return values in
parallel. Note that the answer may be nondeterministic.
Collect<mt_loop_traits::Mult> - this multiplies all of the
return values in parallel
Collect<mt_loop_traits::Div> - this divides all of the
return values in parallel. Note that the answer is nondeterministic.
For example, Collect<mt_loop_traits::Add> is rougly equivalent to the following loop:
for (int i = start; i < stop; i += step) {
retval += function(args);
}
##NOTE FOR PGI USERS
pgcc needs the -c9x flag in order to correctly process variadic macros (which
are used in qthread.c) and the PRIuMAX format definitions (used in qalloc.c).
Use the CFLAGS variable to add this flag. Note that pgcc's support for the full
C90/C99 standards is lousy, so most C90/C99 features that COULD be used are
avoided.
##NOTE FOR IBM XL USERS make check will probably fail with the error:
xlc++: 1501-210 command option t contains an incorrect subargument
.../.libs/libqthread.so: could not read symbols: Invalid operation
This does not mean that the library did not compile correctly, but instead
means that your libtool is probably broken (most are). The problem seems to be
that the wrapper script (testloop) is created with incorrect arguments to
xlc++. The other wrapper scripts (e.g. test1/test2/test3/testq) all have the
correct arguments, and if you modify testloop so that $relink_command uses the
-Wl,--rpath -Wl,directory syntax rather than the -rpath,directory syntax,
it would work just fine.
Old versions of GCC do not handle builtin atomics correctly on this platform.
The non-existence of __sync_fetch_and_add() cannot be reliably detected, so to
use those compilers, you probably need to configure with
--disable-internal-spinlock.
The Tilera cache coherency protocols, as of the TileGX boards, appear to be somewhat buggy for large multithreaded programs. And by buggy I mean they cause kernel panics (at least, I haven't been able to demonstrate data corruption yet). Thankfully, you can pick from several cache coherency protocols, and one of them is more stable than the default. What I have found that seems to be more stable, if not perfectly stable, is to force the cache coherency protocol to hashed. The way you do this is with a boot argument to the Tilera kernel. The tile-monitor command I use is this:
`tile-monitor --net <tilera> --hvx ucache_hash=all --`
Good luck!