RFR: 8263551: Provide shared lock-free FIFO queue implementation

[Kim Barrett]

On Mon, 15 Mar 2021 19:54:35 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this change that is mainly code motion? It creates a generalized lock-free queue implementation based on G1DirtyCardQueueSet::Queue, which will be used by JDK-8236485 in the future.
>> 
>> The shared LockFreeQueue is similar to the existing LockFreeStack. The notable difference is that the LockFreeQueue has an additional template parameter for whether to use GlobalCounter::CriticalSection to avoid ABA problem.
>> 
>> -Man
>
> src/hotspot/share/utilities/lockFreeQueue.inline.hpp line 60:
> 
>> 58:     LockFreeQueueCriticalSection<rcu_pop> cs(current_thread);
>> 59: 
>> 60:     T* result = Atomic::load_acquire(&_head);
> 
> A related question about memory ordering. Are these two load_acquire() really necessary? They are not paired with any release_store().
> I think they can be normal Atomic::load(), as append() and pop() already have Atomic::xchg() and Atomic::cmpxchg() to enforce ordering.

The ordering of xchg in append only affects the writing thread.  It does nothing for the reader side.  The second load_acquire pairs with the set_next (a release_store) in append.  However, it's always (one way or another) followed by a conservative cmpxchg, so does seem possible to weaken.  The first load_acquire is a "consume", but we don't have that and upgrade to acquire.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2986