Hi,
IMO, the synchronization can be called by the application as if the application does it then it can decide to call sync only when a thread writes to the shared buffer. whereas if implementation has to do the sync then it will have to call it every time before scheduler despatches the buffer. This synchronization is needed only when a buffer is queued between threads using odp_queue_enq as odp_schedule() guarantees that only one buffer gets processed in a core at any point of time. Regards, Bala On 2 September 2014 19:16, Bill Fischofer <[email protected]> wrote: > The ODP queue APIs are guaranteed to be muticore and thread safe, so if > such additional calls were needed it would be a bug against them. > > > On Tue, Sep 2, 2014 at 8:32 AM, Ola Liljedahl <[email protected]> > wrote: > >> If a thread writes to a buffer or some other memory only reachable through >> this buffer and then enqueues the buffer on a queue, is there still a need >> for a barrier (e.g. odp_sync_stores()) before calling odp_queue_enq()? >> >> I assume that odp_queue_enq() includes (store-release) barrier semantics >> (possibly implicitly by the use of spin locks). >> >> I would think that the only way for another thread to be able to read this >> buffer (or associated memory) would be to dequeue the buffer (and thus >> include a load-acquire barrier). The buffer pointer cannot be obtained >> before all remote stores have been made visible. The buffer being passed >> from producer thread to consumer thread would thus be properly >> synchronized. >> >> We probably need more specific barrier and synchronization calls in ODP. >> ARMv8 has separate load-acquire and store-release barriers that could be >> useful from other places than lock implementations. >> >> -- Ola >> >> >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> http://lists.linaro.org/mailman/listinfo/lng-odp >> >> > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp > >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
