Till Straumann wrote:
>
> I completely agree. That's why I suggested to just disable interrupts while copying
> small multiple word data types (such as scalar doubles). This should be quite
> efficient
> and not affecting interrupt latency very much.
> AFAIK, this could be done at a small number of places, namely in the
> putXXXDouble routines.
The taskLock() (NB an intLock() is unnecessarily strong) would also need
to be in any record or device code which updates a multi-word field of its
records. Given the large number of doubles which occur in record support
modules this won't be quite as easy as you suggest. However I suspect
that only the cheaper MVME162 CPUs will need this for doubles as they use
software floating-point. Other CPUs will get the FP co-processor to write
doubles, and those operations are probably not interruptable. I've not
checked the compiler output though, I'm just guessing.
- Andrew
--
New country, job, address, car and signature; same old Andrew Johnson
- References:
- database race condition? Till Straumann
- Re: database race condition? Marty Kraimer
- Re: database race condition? Till Straumann
- Re: database race condition? Marty Kraimer
- Re: database race condition? Till Straumann
- Re: database race condition? Marty Kraimer
- Re: database race condition? Till Straumann
- Navigate by Date:
- Prev:
Re: Time Stamping Ned Arnold
- Next:
Re: Interrupt message Marty Kraimer
- 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: database race condition? Till Straumann
- Next:
MEDM 2.3.5a Released Ken Evans
- 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
|