RFR: JDK-8220671: Initialization race for non-JavaThread PtrQueues

[Roman Kennke]

>>> I've tested it against my stress test and Shenandoah test suite, and all seems fine.
>>> Is the extra locking around assignment of global state needed? I think the locking in threads_do() is sufficient?
>>
>> The locking over "_all_active = active;" looks sane to me. This patch has no locking in threads_do(), or am I missing something?
>>
>> cheers,
>> Per
>>
>>> Roman
> 
> Right, there's no locking in (non_java_)threads_do, by design.

I don't see how this is supposed to work. There's code that modifies the 
list, and there's code that iterates the list, and in the absense of 
other synchronization (e.g. participation in safepoints), they need to 
be protected by the same locks, no? What am I missing?

> But looking at this again, the expanded exposure of the
> NonJavaThreadsList_lock is making me regret that it's also being used
> to protect the synchronize() in remove_from_the_list. If an iterator
> were to try to lock that mutex while some NonJavaThread was on its way
> out, we'd deadlock.

Why?

> The one new use of the mutex being added by this
> change doesn't introduce such a problem, but still... I think it's
> easy to avoid that problem by adding a new mutex just to protect the
> synchronize call.

Uh, no? Wouldn't that be missing the point above? We can't just 'avoid' 
the problem by protecting something by two mutexes that ought to be 
under one mutex.

Or what am I missing?

Roman