las3_pub / predictable_parallel_patterns

Remove easy profiler for now. It might be useful for later on to get a grasp of general behaviour, but because of its issues with coroutines it is not worth profiling code with it right now.

It is now possible to use a memory mapped stack that throws a SIGSEV if thes coroutine stacks are exhausted.

Remove the strict static memory allocation scheme in favour of placing objects on the heap at startup. This still keeps the requirements posed for modern, high performance embedded systems, but makes APIs a lot cleaner.

This version runs through our initial fft and fib tests. However, it is not tested further in any way. Additionally, we added a locking deque, potentially hurting performance and moving away from our initial goal.

It is still not working, however we now have no more redundant code, making debugging it simpler.

Everything so far is untested. We only made sure tha fast path still seems to function correctly. Next up is writing tests for both the fast and slow path to then introduce the slow path. After that we can look at performance optimizations.

We changed how the memory is allocated from passing char* buffers to then store objects into to creating 'fat objects' for all scheduler state. This eases development for us, as we can make changes to data structures without too much effort (e.g. add a second array to manage tasks if required).

This allows us to more easily handle them and makes their interface closer to std::thread.

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.

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.

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.