Hi Ola,
Please see below general comment about your approach.
> +typedef enum {
> + /** Relaxed memory order, no ordering of other accesses enforced */
> + ODP_MEMORDER_RLX,
> + /** Acquire memory order, later accesses cannot move before
> + * acquire operation */
> + ODP_MEMORDER_ACQ,
> + /** Release memory order, earlier accesses cannot move after
> + * release operation */
> + ODP_MEMORDER_RLS
> +} odp_memorder_t;
Why do you have 3 memory models while C11
has 6?
Are you aware about gcc __atomic built extenstion?
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
They follow C11 quite closely with few caveats (like run-time
vs built time). Why don't you use those, instead of implementing
them by yourself?
What is the need to reimplement those in ODP?
I am not sure, it seems to me that Petri raised similar point.
In ODP we need to provide atomic operations that map to
possible h/w accelerations that SOCs come up with, like
Octeon atomic and ARM8.1A atomic instructions. If we just
need atomic function for general purpose memory, those
IMHO should come up from somewhere else (like compiler,
C11 implementation, etc).
Basically if linux-generic needs
some of atomic C11 style primitives it could use __atomic
builtins directly or with some tiny wrapup api, that deals
with gcc/clang differences, but those should not be exposed
as ODP apis. I think that point was raised during discussion.
BTW linux-generic atomic implementation (one that implements
ODP API) could use __atomic with relaxed option to do required
operation, but without barrier, if you are not happy with current
implementation that uses old __sync builtins.
Thanks,
Victor
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
