Page History

...

When after this, the consumer calls a callback, the callback must be able to invoke the consumer again. This is allowed because the thread-local variable corresponds to the top of the stack. Therefore, code that is not aware of this KIP (all programs in existence till now) will continue to work as before.
The callback may now chose to access the thread-local variable (using getThreadAccessKey), and store the access key on the local-variable of another thread (using setThreadAccessKey), thereby allowing that thread to access the consumer. Because acquire  immediately and atomically stores a new access key, it is not possible for multiple threads to use a valid access key concurrently.

When a callback passes its access-key to another thread, it must wait for with returning from the callback until that other thread to complete before returning from the callbackhas completed invoking the consumer.

When release is invoked, we first validate that the top of the stack is equal to the thread-local variable. If it is not equal, it means that a callback didn't wait for the other thread to complete invoking the consumer. After the check we pop the top value of the access-key stack, and then restore the new top of the stack to the thread-local variable, or if the stack is now empty we clear the thread-local variable.

...