las3_pub / predictable_parallel_patterns

The __thread implementation of thread local, static variables seems more efficient, so we activate this by default. If it is (for some reason) not available/slower than the pthread version, one can toggle it for the specific system/processor later on using macros.

We do this to properly separate the cache alginment logic in the next step, allowing us to port all cache aligned objects without worrying about portability.

We do so by pulling out the profiling macros in our own iclude file. In the future we might even be able to use this to build up further visualisations of the executing programm.

Use only placement new on pre-allocated memory. This makes sure that we have to have no assumptions on the inital state of the memory region.

This lead to some bug-fixes that covered move constructors not correctly assigning memory. We might clean this up further by only allowing in place creation of these types (placement new).

There are serval ways we could optimize the calls, but for now this should be enough for first tests.

The current solution is not clean, but allows us to change error handling later on without missing any point in the programm where we would want to use it.

This implementation allows one to add the deque_item property to any class and then manage pointers to these items in a deque. We currently use a spinlock for concurrent access.

The lock was not released when an split_task was executed. We did a dirty fix by allowing the method to unlock the lock itself, but this has to be done cleaner in the future.

This means that high level tasks can be stolen and lays the groundwork for implementing different tasks like classic work stealing.

This will be used for storing thread tasks aligned in continous memory, allowing different theads to work on the data without interfearing.

Right now no work can be spawned, we simply have a proove of concept that we start up each thread, work for the master to finish and then synchronize back to the main thread.

See NOTES.md for details, basically std::thread can use dynamic memory allocation internaly and we want to prevent that.

The local storage per thread is only a pointer, this must be assigned AFTER the local storage object has moved to it's final location (e.g. on the stack of the caller). We might even change this a little further in the future to make the location of the state object more transparent.

The first draft of the internal threading component is currently only implemented using the c++11 std::thread, pthread support will be added next.