I think we really want the devAsynXXXArray device support to work as it should standalone, with no additional records needed. I'm hoping the fix I proposed will fix Zen's problem.
Mark
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Hinko Kocevar
Sent: Wednesday, July 25, 2012 4:59 AM
To: [email protected]
Subject: Re: asynPortDriver
On 07/25/2012 12:35 AM, Mark Rivers wrote:
> Hi Zen,
>
> I think we were on the right track with the gotValue check, but the timing problem is a little different.
>
> Here is the problem I thought might be happening:
>
> - Your driver calls doCallbacksInt32Array.
> - This results in a call to interruptCallbackInput in asyn/devEpics/devAsynXXXArray.h
> - interruptCallbackInput copies the data to the waveform record VAL field and then calls scanIoRequest
> - Another interrupt occurs before the record processes and calls devAsynXXXArray::processCommon
> - gotValue will be 1 because the processCommon has not yet reset gotValue=0
>
> You showed that this problem can happen, but only at higher callback rates.
>
> Here is the problem I now think is happening:
> - Your driver calls doCallbacksInt32Array.
> - This results in a call to interruptCallbackInput in asyn/devEpics/devAsynXXXArray.h
> - interruptCallbackInput copies the data to the waveform record VAL field and then calls scanIoRequest
> - scanIoRequest calls processCommon, which sets gotValue=0
> - Another interrupt occurs before the record has finished posting monitors. It overwrites the data in the record. It calls scanIoRequest again.
> - The waveform record then processes twice with the data from the second callback.
>
> This appears to be what you are seeing.
>
> I just realized that the problem is that there no mutex preventing the callback from overwriting the waveform data at any time when the waveform record is processing, which is bad. Note that is problem is confined to I/O Intr scanned waveform records, it does not happen on other records that use a ring buffer.
Could this situation be avoided by using longin record "in front" of
waveform record?
Longin is processed with SCAN=I/O Intr, its FLNK points to (first)
waveform which is processed with SCAN=Passive. Longin is just
incremented at each trigger to make Asyn happy and get things rolling
for the waveform.
Would this make use of the ring buffer (for longin) and still allow the
user to see the data at every trigger?
Regards,
Hinko
--
Hinko Kocevar
Software development engineer
Instrumentation Technologies d.d.
Velika pot 22, SI-5250 Solkan - Slovenia
T:+386 5 3352600, F:+386 5 3352601
E-mail: [email protected]
http://www.i-tech.si
The information transmitted is intended solely for the
addressee and may contain confidential and/or privileged
information. Any review, retention, disclosure or other use
by persons other than the intended recipient is prohibited.
If you received this in error, please notify the sender and
delete all copies.
- Replies:
- Re: asynPortDriver Hinko Kocevar
- References:
- asynPortDriver Szalata, Zenon M.
- RE: asynPortDriver Mark Rivers
- RE: asynPortDriver Szalata, Zenon M.
- RE: asynPortDriver Mark Rivers
- RE: asynPortDriver Szalata, Zenon M.
- RE: asynPortDriver Mark Rivers
- RE: asynPortDriver Szalata, Zenon M.
- RE: asynPortDriver Mark Rivers
- Re: asynPortDriver Hinko Kocevar
- Navigate by Date:
- Prev:
Re: asynPortDriver Hinko Kocevar
- Next:
Re: asynPortDriver Hinko Kocevar
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: asynPortDriver Hinko Kocevar
- Next:
Re: asynPortDriver Hinko Kocevar
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|