Multithreaded concept

Multithreaded concept for our multi-library SW setting:

Consider the "include" diagram for SW:

• Some of the libraries + Singular may need their own TLS (but try to avoid the need of TLS)
• New auxiliary library xthread will provide the basic TLS support for C++ libraries:
  • Common TLS Structure that accommodates placeholders for all of our libs: e.g. void* common_tls[MAXLIBID] = 0,0,0...0;
  • Common means for accessing it: static inline void* TLS(const unsigned int LIBID){ return TLS().common_tls[LIBID]; }
  • new_thread, which should take Init and Done as well as Run function pointers for setting up TLS for all the needed Libs: in their dependency order!
  • LIBIDs definitions for each library
  • basis should be libatomic)ops (http://www.hpl.hp.com/research/linux/atomic_ops/index.php4)

Small steps (plan):

• Start with SW
• Make sure findexec ("libresources") is used in a readonly way and thus is thread-safe.
• Cristian makes his variant of omalloc - thread-safe
• since factory is not thread-safe and uses NTL - guard all the calls into factory with a lock: TODO for a HiWi, this should better be ifdef'ed depending on HAVE_THREADS(!?)
• make sure coeffs do NOT deal with NTL directly!!!
• the rest of our libs: libpolys, kernel, Singular (numeric?) should make use of the above "Multi-library concept":
  1. identify all the global variables
  2. Document all readonly global variables (with a single global initialization)
  3. Guard shared ones with locks if they are not readonly vars, examples: ?!
  4. The rest should be put into a LIBTLS Structure for that lib. - but first we simply assume that we have "__thread" and mark them with this directive, maybe using a conditionaly defined macro __THREAD, depending on HAVE_THREADS. Examples: currRing, options (value/test)...
  5. Each lib should provide its own Init/Done_lib global functions that are supposed to know about corresponding functions for underlying libraries, and should call them in correct order: easy with the left libraries(?)
  6. Each library should have its own LIBID and TLS macro and access thread local variables via: TLS().variable

Note: for multi-threaded programming it would probably be best to use some commonly used framework. Consider using: Threading Building Blocks (or Parallel Building Blocks) from Intel or switching to C++11 (cf. Threads and Shared Variables in C++11).

Note: Why avoid locks?

Note: as the number of processing units (CPUs, Cores, Hyperthreads etc...) increases it makes more sense to deal with (asynchronous) tasks or jobs to be done (see C++11::thread::async) rather than with individual threads...