Racy test failure: segfault in map::tree_bins::concurrent_tree_bin

[jonhoo]

Racy test failure: segfault in map::tree_bins::concurrent_tree_bin

[domenicquirl]

Also unable to reproduce on Windows stable as of now. The location makes me think of
the "race" discussed in #72 (review) as a likely candidate. We talked about how the tokens are required because they might have to be available before the waiting threads parks. However, your concern there may still be valid wrt. the reading thread seeing the stored WAITER in lock_state, the stored waiter as non-null, but in the meantime the writing thread re-checks lock_state and not only swaps out the waiter, but cleans it up with into_owned. Might need to be defer_destroy, to handle the above case.

[domenicquirl]

I need to leave now and will have to come back to this (and maybe setup a Linux nightly for testing). If you have time, maybe try this out in the meantime.

[jonhoo]

Hmm, I wonder why the Java code does not have to deal with that...

[domenicquirl]

If this ends up being the cause, it would be because the reading thread holds a reference to the Thread handle in question, so it cannot get GC'd (they don't [have to] use atomic pointers)

[jonhoo]

Ah, that's a good point. Let me try making that a deferred destroy.