Add notes on futex linux syscall.

This might allow us to do lock free, conditional waits in our stealing loop.

NOTES.md

@@ -4,6 +4,36 @@ A collection of stuff that we noticed during development.
 Useful later on two write a project report and to go back
 Useful later on two write a project report and to go back
 in time to find out why certain decisions where made.
 in time to find out why certain decisions where made.
 
 
+## 02.08.2019 - Ideas for sleeping threads when no work is available
+
+A new requirement discovered during theoretical analysis is to
+sleep threads when there is no work left to do. This, in
+contrast to classic Arora, Blumofe and Plaxton (ABP) yielding
+mechanism, we wan threads without work to allow LOWER PRIORITY
+processes to take over. Simply yielding is not sufficient,
+as it will not consider lower priority tasks.
+
+Therefore, we need to actually sleep/wait in the time without any
+work. This sleep is a conditional sleep: once work is available,
+the thread should wake up and perform it to make sure high priority
+processes finish in time. Usually one would use condition variables
+for this kind of wait, but a posix condition variable requires to
+hold a mutex to be race free, which we would like to avoid to keep
+the whole system lock free (and thus keep our progress guarantee).
+
+To keep a lock free mutex we found the `futex` linux syscall.
+This is platform dependent on Linux, but as a system call is required
+for any kind of sleep functionality we think it is ok to go for
+OS specific primitives to implement this (a fallback for locking,
+posix mutex + condition variables is always possible).
+
+Some information can on `futex` can be found [in this bolg post](https://gustedt.wordpress.com/2011/01/28/linux-futexes-non-blocking-integer-valued-condition-variables/)
+and [in the liunx man-pages](http://man7.org/linux/man-pages/man2/futex.2.html).
+Basically, it allows to conditionally sleep a thread based on an
+atomic compare and exchange operation on a 32 bit word,
+which is exactly what we need for our lock free sleep based on an
+indicator variable of available work.
+
 ## 31.07.2019 - First benchmark of implementation
 ## 31.07.2019 - First benchmark of implementation
 
 
 We chose the implementation that allocates one invocation instance
 We chose the implementation that allocates one invocation instance