On 04/11/2014 07:29 PM, Gedare Bloom wrote:
On Fri, Apr 11, 2014 at 11:15 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de>  wrote:
>---
>  cpukit/score/include/rtems/score/percpu.h |    8 +++++---
>  1 files changed, 5 insertions(+), 3 deletions(-)
>
>diff --git a/cpukit/score/include/rtems/score/percpu.h 
b/cpukit/score/include/rtems/score/percpu.h
>index 75ff3e2..92a6e8a 100644
>--- a/cpukit/score/include/rtems/score/percpu.h
>+++ b/cpukit/score/include/rtems/score/percpu.h
>@@ -424,11 +424,13 @@ extern Per_CPU_Control_envelope _Per_CPU_Information[] 
CPU_STRUCTURE_ALIGNMENT;
>    _ISR_Enable( isr_cookie )
>  #endif
>
>+#define _Per_CPU_Get_snapshot() \
>+  ( &_Per_CPU_Information[ _SMP_Get_current_processor() ].per_cpu )
>+
I think of a snapshot as a copy of some data that might change in the
future. Since this gets the reference without making even a
shallow-copy, I don't know what is being "snapshotted" or what
guarantees if any are made about the snapshot.


If you read the processor index of the current processor in a context which allows thread dispatching, then you may already run on another processor right after the read instruction. There are very few cases in which this makes sense (here we can use _Per_CPU_Get_snapshot()). All other places must use _Per_CPU_Get() so that we can add checks for RTEMS_DEBUG.

Do you have a better name?  I will add the comment above to the source code.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Reply via email to