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.

I am not sure if this is appropriate, but it works and is no focus of this project.

Make sure that the guard page leads to sigsegv as expected.

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.

The cas size could exceed an unsigned long, so we use the correct cas_integer type for the traded_cas_field representations.

We yield after num_thread failed steals in a row. This parameter can be tuned for better performance, but we stick to a sensible default just to prevent massive spinning.

Older CMAKE versions wont work with export targets in different directories. For now we simply add the context_switcher manually to the export target of pls.

We still see very sporadic crashes, however the current version is at least a starting point for refactoring and debugging. Next steps have to be to re-enable tooling support (i.e. add code to let sanitizers do their work).

The current version has race conditions and is hard to debug (especially because of the fibers, if a wrong thread executes on a fiber we get segfalts very fast). To combat this mess we now refactor the code bit by bit while also adding tests where it can be done with reasonably effort).

The project is currently really messy and there are sporadic sigsevs. This indicates that we still have a race in our code. Thread Sanitizer does not work with our current implementation, as it needs annotations for fibers.

The next step is to clean up the project and maybe add thread sanitizer support to our fiber implementation. This should help finding the remaining bugs.

The deque trades tasks when stealing. Right now only the fast local path is tested and implemented. For the next step to work we also need to add the resource stack and resource tarding to the system.

The current state shows the minimum actions taken to execute a parallel call: get the thread local, find the active frame, execute on the next frame and return to the active frame.

The rationale to do an custom implementation is that the existing solutions are quite a bit slower and/or require more memory.

The idea is to exclude as many sources as possible that could lead to issues with contention and cache misses. After some experimentation, we think that hyperthreading is simply not working very well with our kind of workload. In the future we might simply test on other hardware.

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.

The main issue seems to still be the fact that we have a lock free protocol where a steal can be pending. We plan to remove this fact next by introducing a protocol that works on a single atomic update.

The start_chain property does not make sense, as chains are purely 'virtual', i.e. they only fully exist when walking through the computation (by patching them on important events). We initially added the property as a helper for better runtime and simpler implementation, but we think without it we will not get as much inconsistency in the runtime state. Performance can be 're-added' later on.