From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl Sent: Thursday, April 23, 2015 8:40 PM To: Maxim Uvarov Cc: LNG ODP Mailman List Subject: Re: [lng-odp] Atomics
On 22 April 2015 at 13:24, Maxim Uvarov <maxim.uva...@linaro.org<mailto:maxim.uva...@linaro.org>> wrote: On 04/22/15 14:20, Maxim Uvarov wrote: On 04/22/15 13:34, Nicolas Morey-Chaisemartin wrote: On 04/22/2015 11:39 AM, Maxim Uvarov wrote: In that case what you need is. That is odp API: ./include/odp/api/atomic.h That is platfrom implementation (linux-generic): ./platform/linux-generic/include/odp/atomic.h That is some internal functions which linux-generic platfrom does. ./platform/linux-generic/include/odp_atomic_internal.h So that what you need is move ./platform/linux-generic/include/odp/atomic.h to ./platform/your-platfrom/include/odp/atomic.h and re implement functions there. Is that original question? Best regards, Maxim. That's what I did. But our implementation is mostly based on the linux-generic now. And as I had to implement almost the same atomic functions twice, I was thinking it would make sense to refactor this code in the linux-generic tree too. Nicolas Ok, got it now. Ola, I think that it can be reworked and because all odp_timer.c, odp_ticketlock.c and odp_rwlock.c use _ODP_MEMMODEL_RLX they can also use api function, not _internal.h right? The implementation of synchronization operations (locks, barriers etc) use all kind of memory orderings, especially acquire and release. I don't know and really don't care exactly how the final solution will look like, the person who does the work will have to find something that works. But we should agree on some prerequisites. Should the atomic operations in linux-generic/include/odp_atomic_internal.h become public (that would be the simplest solution me thinks) or stay private? If stay private, is there some way for the public operations in include/odp/api/atomic.h to use the operations in odp_atomic_internal.h which are not considered public? I.e. can you implement a public API using non-public (private) definitions? Those should stay private. If the compiler does not support __atomic_xxx, but supports __sync_xxx, linux-generic/include/odp/atomic.h could be modified to #ifdef between __atomic and __sync. That would narrow the problem to re-implement only those linux-generic internal atomics that are really used and cannot be changed to API atomics. It seems most _odp_atomic_ calls are really needed, but only these combinations are actually used. Some of these (in timer) are behind #ifdefs. It would be better to pick only one implementation (e.g. 32, 64 or 128 bit) and remove #ifdefs, otherwise the code will be not tested and thus rotten… _odp_atomic_u32_load_mm(…, _ODP_MEMMODEL_RLX) _odp_atomic_u32_load_mm(…, _ODP_MEMMODEL_ACQ) _odp_atomic_u32_cmp_xchg_strong_mm(…, _ODP_MEMMODEL_ACQ, _ODP_MEMMODEL_RLX) _odp_atomic_u32_sub_mm(…, _ODP_MEMMODEL_RLS) _odp_atomic_u32_store_mm(…, _ODP_MEMMODEL_RLS) _odp_atomic_u64_store_mm(…, _ODP_MEMMODEL_RLS) _odp_atomic_u64_load_mm(…, _ODP_MEMMODEL_RLX) _odp_atomic_u64_xchg_mm(…, _ODP_MEMMODEL_RLX) _odp_atomic_u64_cmp_xchg_strong_mm(…, _ODP_MEMMODEL_RLX, _ODP_MEMMODEL_RLX) _odp_atomic_u128_cmp_xchg_mm(…, _ODP_MEMMODEL_RLS, _ODP_MEMMODEL_RLX) _odp_atomic_u128_xchg_mm(…, _ODP_MEMMODEL_ACQ_RLS) _odp_atomic_u128_xchg_mm(…, _ODP_MEMMODEL_RLX) _odp_atomic_flag_xxx() Could this list be shrunken to by e.g. removing 128 bit and flag … or even further always use only 32 or only 64 bit? Trade-off e.g. 32 bits more memory used per lock to half (or quarter) the porting effort? -Petri
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
