On 4/5/19 12:01 PM, Daniel D. Daugherty wrote:
> On 4/5/19 8:37 AM, Doerr, Martin wrote:
>> Hi everybody,
>>
>>> I think was fixed with:
>>> 8202080: Introduce ordering semantics for Atomic::add/inc and other RMW atomics
>>> You should get a leading sync and trailing one with the default conservative
>>> model and thus get proper memory ordering.
>>> Martin, I'm I correct?
>> Exactly. Thanks for pointing this out. PPC uses the strongest possible ordering semantics with memory_order_conservative (default parameter).
>> I've seen that comment about PPC in "void ThreadsList::inc_nested_handle_cnt()". This function could get replaced.
>
> Okay so we need a new bug to update these two Thread-SMR functions:
>
> src/hotspot/share/runtime/threadSMR.cpp:
>
> void ThreadsList::dec_nested_handle_cnt() {
> // The decrement needs to be MO_ACQ_REL. At the moment, the Atomic::dec
> // backend on PPC does not yet conform to these requirements. Therefore
> // the decrement is simulated with an Atomic::sub(1, &addr).
> // Without this MO_ACQ_REL Atomic::dec simulation, the nested SMR mechanism
> // is not generally safe to use.
> Atomic::sub(1, &_nested_handle_cnt);
> }
>
> void ThreadsList::inc_nested_handle_cnt() {
> // The increment needs to be MO_SEQ_CST. At the moment, the Atomic::inc
> // backend on PPC does not yet conform to these requirements. Therefore
> // the increment is simulated with a load phi; cas phi + 1; loop.
> // Without this MO_SEQ_CST Atomic::inc simulation, the nested SMR mechanism
> // is not generally safe to use.
> intx sample = OrderAccess::load_acquire(&_nested_handle_cnt);
> for (;;) {
> if (Atomic::cmpxchg(sample + 1, &_nested_handle_cnt, sample) == sample) {
> return;
> } else {
> sample = OrderAccess::load_acquire(&_nested_handle_cnt);
> }
> }
> }
>
> I'll file a new bug, loop in Robbin, Erik O and Martin, and make
> sure we're all in agreement. Once we decide that Thread-SMR's
> functions look like, I'll adapt my Async Monitor Deflation
> functions...
>
> Dan