Experimental Physics and
Industrial Control System

Eric Norum <[email protected]> · Thu, 31 May 2012 08:42:59 -0700

On May 31, 2012, at 8:08 AM, Andrew Johnson wrote:

> Hi Eric,
> 
> On 2012-05-30 Eric Norum wrote:
>> 
>> Actually the asyn devEpics layer is simpler than described above.
>> - It always sets the record TIME field from the pasynUser->timestamp in
>> the device support interrupt callback or read method then returns to
>> higher level record processing code.
>> - The record processing code then
>> overwrites the TIME field unless the TSE field is -2.
> 
> If you do this it is possible for a client that is doing ca_get operations (or 
> even some other record that might have its TSEL pointing to this record's TIME 
> field) to see the time set by the devEpics layer, even if the record 
> subsequently overwrites the TIME field.  Since the TIME field is a structure 
> with two 32-bit components it is even possible for such a client or record to 
> see the seconds part of the old time-stamp and the nanoseconds from the new 
> one (or vice-versa) if the interrupt happened to occur in between it reading 
> the two parts.
> 
> I suspect some of them do, but I don't think device support should be updating 
> *any* publicly visible record fields from inside an ISR, since it can't be 
> sure that the record isn't currently locked and having field values being read 
> out of it.
> 

Who said that we were doing this from an ISR?   
I guess that I wasn't clear enough.    The devEPICS code that's writing to the .TIME field is actually in an interrupt callback thread -- at task-level. 
This is acceptable isn't it?   

-- 
Eric Norum
[email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System