|
Message-ID: <20200920171707.GC3265@brightrain.aerifal.cx> Date: Sun, 20 Sep 2020 13:17:08 -0400 From: 'Rich Felker' <dalias@...c.org> To: sidneym@...eaurora.org Cc: musl@...ts.openwall.com Subject: Re: Hexagon DSP support On Sun, Sep 20, 2020 at 08:12:47AM -0500, sidneym@...eaurora.org wrote: > > > > > [...] > > > > > +#define a_barrier a_barrier > > > > > +static inline void a_barrier() > > > > > +{ > > > > > + __asm__ __volatile__ ("barrier" ::: "memory"); } > > > > > > > > Is the barrier implied in memw_locked? If not, there need to be > > > > explicit barriers in all the atomic functions. > > > > > > Yes, if there is any memory access on the reserved address the > > > reservation is lost and the predicate is false. > > > > That's not what a barrier means. The question is whether it orders all > access > > to *other* memory, not the address with the reservation on it. > > In other words, musl's a_*() atomics need to be full seq_cst model > > operations, not relaxed atomics. > > Per our spec: > "Threads in the Hexagon processor follow a sequentially consistent memory > model at a packet > granularity. Threads interleave their memory operations with one another in > an arbitrary but > fair manner. This results in a consistent program order that is globally > observable by all > threads in the same order." Can you clarify or provide a reference for what 'packet granularity' means? If there's actually a full builtin seq_cst order I don't see what the barrier instruction exists for to begin with. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.