las3_pub / predictable_parallel_patterns

Currently once we are serial no more parallel strains are executed. However, this could be changed using strain local resources in the future.

The strain_local resources can be used to get unique IDs for resources that would, in a serial execution, only be used once in the call chain. This is a first prototype implementation and needs further tesitng. The current implementation adds linear overhead to each steal proportional to the number of used  resources. We might be able to reduce it, but for a first version it is fine.

The flag can be used to run code annotated with PLS outside of a scheduler environment,
i.e. the app does not crash if the code is called without context. The compile option
allows to omit all spawn and sync calls during compilation, creating the equivalent serial code.

Basic profiling works. Next steps are to 'refine' the interface, i.e. allow to disable parts of the profiling and better output for some stats. Maybe look at storing/loading the DAG's with stats to/from disk.

Add key-points required to capture an execution DAG. Currently all data is in-memory and printed out. In future work it would be good to store the DAG's and/or process them further.

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 fixed the bug in tsan causing it to crash after creating/deleting many fibers, because of that there is no need for this cache mechanism (you have to use the most recent clang build with the patch for it to work thought).

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.

Tsan does not cope well with rapidely destroyed/created fibers. As it is currently too much effort to fully investigate the tsan issue we work around it by caching the shourt lived fibers based on their stack base address. This allows us to use thread sanitizer for now.

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.