I think there are problems in sampler_usr.c related to the use of fifo->out.
Normally it is the responsibility of sampler_usr.c to store fifo->out
and sampler.c only loads it. But in the case that the fifo is full,
sampler.c overwrites the oldest data and must also store fifo->out.
An excerpt from sampler_user.c:
while ( samples != 0 ) {
while ( atomic_load_explicit(&fifo->in, memory_order_acquire)
== fifo->out ) {
This looks a bit fishy, but might be OK.
/* fifo empty, sleep for 10mS */
delay.tv_sec = 0;
delay.tv_nsec = 10000000;
nanosleep(&delay,NULL);
}
/* make pointer to fifo entry */
tmpout = atomic_load_explicit(&fifo->out, memory_order_acquire);
newout = tmpout + 1;
if ( newout >= fifo->depth ) {
newout = 0;
}
dptr = &data[tmpout * (fifo->num_pins+1)];
/* read data from shmem into buffer */
for ( n = 0 ; n < fifo->num_pins ; n++ ) {
buf[n] = *(dptr++);
}
/* and read sample number */
this_sample = dptr->u;
if ( atomic_load_explicit(&fifo->out, memory_order_acquire) !=
tmpout ) {
/* the sample was overwritten while we were reading it */
/* so ignore it */
continue;
} else {
/* update 'out' for next sample */
atomic_store_explicit(&fifo->out, newout,
memory_order_release);
}
I think the idea is to load fifo->out, read the data, then read
fifo->out a second time to make sure the data wasn't overwritten while
it was being read. But the memory order constraint for the second load
(memory_order_acquire) is not strong enough to prevent the read of data
from moving to after the second load. I think it may even be possible
for the two loads to be combined into one.
Since memory barriers are being used in the non C11 case, this will
probably work for now. But it won't with true partially-ordered
memory_order_acquire.
It might be possible to correct this, although there may be other
problems lurking.
Is the overwrite really required? Drop, as in streamer, is much simpler.
--
Chris Lesiak
Principal Design Engineer, Software
LI-COR, Inc.
[email protected]
Any opinions expressed are those of the author and
do not necessarily represent those of his employer.
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
