On Fri, Apr 11, 2014 at 2:00 PM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > 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. > I don't have a better name. The explanation helps. In case the processor changes, then it makes sense to call it a snapshot since it can reflect stale state.
> -- > 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
