Never block waiting for reserved thread.
Dump reserved thread stack if it does not make the rendezvous

…95-ReservedThreadExecutor

fix warnings

Signed-off-by: Simone Bordet <simone.bordet@gmail.com>

Signed-off-by: Simone Bordet <simone.bordet@gmail.com>

Signed-off-by: Simone Bordet <simone.bordet@gmail.com>

Signed-off-by: Simone Bordet <simone.bordet@gmail.com>

avoid waiting 1s

If a reserved thread does not rendezvous, put it back on the bottom of the stack.

Even more paranoid checks:
 + test if an missed offer was for a thread that removed itself from the stack
 + test if a reserved thread is already on the stack before adding it.

Even more paranoid checks:
 + try to poll after remove to check for race in remove

Even more paranoid checks:
 + try to poll after remove to check for race in remove

This is a new approach to #6495.    A call to offer must never block, nor even yield, since to do so give an opportunity for the allocated CPU core to change, defeating the whole purpose of the class.

There is also some reasonable level of diagnostic warnings if a reserved thread misses too many offers consecutively, based on tracking the state of the reserved thread.

Use MAX_VALUE rather than -1 as the stopped marker value.