Experimental Physics and Industrial Control System
Hi Mark,
On 2012-07-24 Mark Rivers wrote:
>
> 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.
>
> I think the solution is to call dbScanLock during the time the array data
> is being modified in the callback.
I haven't looked at your code changes, but I suspect that this is causing the
problem. As a general point no code should ever modify any record field
values unless dbScanLock() has been taken first. On an SMP machine even
reading fields without taking dbScanLock() might give bogus values for some
field types if another processor happens to be writing to the field at the
same time that your code is reading it.
Some record-type authors have also been known to use public fields for
temporary storage of a partially-calculated result while their process()
routine is running, which would become visible if you don't use dbScanLock();
I don't think this applies to any of the Base record types any more, but I
haven't done an audit of them for this.
HTH,
- Andrew
--
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte
- References:
- asynPortDriver Szalata, Zenon M.
- RE: asynPortDriver Szalata, Zenon M.
- RE: asynPortDriver Mark Rivers
- Navigate by Date:
- Prev:
Re: asynPortDriver Hinko Kocevar
- Next:
RE: asynPortDriver Szalata, Zenon M.
- 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 Szalata, Zenon M.
- 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