A full memory barrier would actually work for us but the cost is unacceptable
most of the time.
To get all the performances out of our core, it will be necessary for our ODP
user to be aware the the non-cache coherency and deal with it manually.
However what I'm looking for (as a first step at l
In general, this issue is about - how to support non cache coherent systems.
Additional calls specified for non-coherent systems could be added (to shm and
potentially elsewhere) but should be optional for applications, since it’s
quite tricky to (efficiently) ensure cache coherency in SW. Also
This is regarding ODP 226 (Tests assuming pthreads)
Kalray is facing a problem actually larger than this thread vs process
problem:
The basic question is: when N processors share the same memory (shmem
object),
is it acceptable to force a cache update for the whole shmem'd area for N-1
processors