Majority of platforms are cache coherent, for a  non-coherent platform you’d 
need to define some additional API calls. This is documenting the current 
assumption that application does this …

// data in shared memory
int foo;

Thread A                                                      Thread B

ev = schedule();
msg = event_to_message(ev);

if (msg == UPDATE_FOO) {
    foo++;
    msg = FOO_UPDATED;
    queue_enq(msg);
}

                                                                 ev = 
schedule();
                                                                 msg = 
event_to_message(ev);

                                                                 if (msg == 
FOO_UPDATED) {
                                                                     
printf(“foo is now %\n”, foo);
                                                                 }


… intead of this …

Thread A                                                      Thread B

ev = schedule();
msg = event_to_message(ev);

if (msg == UPDATE_FOO) {
    // Make sure that load of “foo” is not moved before schedule()
    odp_sync_loads();
    foo++;
    // Make sure that store of “foo” is not moved after queue_enq()
   odp_sync_stores();
    msg = FOO_UPDATED;
    queue_enq(msg);
}

                                                                 ev = 
schedule();
                                                                 msg = 
event_to_message(ev);

                                                                 if (msg == 
FOO_UPDATED) {
                                                                     // Make 
sure that load of “foo” is not moved before schedule()
                                                                     
odp_sync_loads();
                                                                     
printf(“foo is now %\n”, foo);
                                                                 }


As you can see it would a lot of waste if application must always sync for 
stores and loads explicitly.

-Petri


From: EXT Nicolas Morey-Chaisemartin [mailto:nmo...@kalray.eu]
Sent: Thursday, November 05, 2015 5:23 PM
To: Bill Fischofer
Cc: Savolainen, Petri (Nokia - FI/Espoo); LNG ODP Mailman List
Subject: Re: [lng-odp] [API-NEXT PATCH] api: sync: update spec and add 
odp_sync_loads


On 11/05/2015 04:21 PM, Bill Fischofer wrote:
Perhaps the note could be changed to read:

ODP synchronization mechanisms (e.g., barrier, locks, queue dequeues) are 
guaranteed to be coherent, so this call is not needed when using those.

No need to specify how coherency is achieved on a given platform for these ops.

This sounds much better.



On Thu, Nov 5, 2015 at 9:05 AM, Nicolas Morey-Chaisemartin 
<nmo...@kalray.eu<mailto:nmo...@kalray.eu>> wrote:
Sorry for the late feedback. I missed this one

On 10/26/2015 05:07 PM, Petri Savolainen wrote:
> Updated odp_sync_stores() specification and added odp_sync_loads
> to pair it. Used GCC __atomic_thread_fence to implement both of
> those.
>
> Signed-off-by: Petri Savolainen 
> <petri.savolai...@nokia.com<mailto:petri.savolai...@nokia.com>>
> ---
...
> +/**
> + * Synchronize loads
> + *
> + * This call implements a read memory barrier. It ensures that all 
> (non-atomic
> + * or relaxed atomic) loads that precede this call happen before any load
> + * operation that follows it. It prevents loads moving from after the call to
> + * before it.
> + *
> + * ODP synchronization mechanisms (e.g. barrier, locks, queue dequeues)
> + * include read barrier, so this call is not needed when using those.
> + *
The API here is fine. What bothers me is the footnote about all ODP sync 
mechanisms calling this.
Because Kalray architecture does not have cache coherency, a read memory 
barrier is *very* expensive.
We have to invalidate the complete cache (cheap) but then refill it later.

What our current implementation does is simply invalidate the appropriate 
structure as needed.
barriers and locks only cause write memory barrier. Queue dequeue also ensure 
that the dequeued struct (packet, timer, buffer, etc.) are up to date with the 
other threads and devices.

_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
https://lists.linaro.org/mailman/listinfo/lng-odp


_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to