Wayne Thornton commented on a discussion on cpukit/dhrl/dhrl.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_150613 > + atomic_store_explicit( > + &ctx->winning_data_ptr, > + (uintptr_t) target_addr, > + memory_order_release > + ); > + } > + > + rtems_barrier_wait( ctx->tail_barrier, RTEMS_NO_TIMEOUT ); > + } > +} > + > +/* Internal Hybrid Barrier Execution */ > +static volatile void *dhrl_fetch_data( > + struct dhrl_control *ctx, > + volatile void *addr_a, > + volatile void *addr_b @gedare I'm sure it does look out of place without context. The volatile qualifiers here are strictly to prevent the compiler from performing dead-code elimination. Because the DHRL worker threads are executing a dead load `(void) *(volatile uint32_t *) target_addr;` just to trigger the physical bus transaction, my understanding of compiler mechanics is that the compiler will silently strip the actual load instruction out at `-O2` if it isn't marked volatile. I kept the signature as `volatile void *` throughout the function chain so the qualification wouldn't be dropped before it reached the worker loop. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_150613 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
