Dear all,
I have been implementing the changes to VxWorks global variable device
support that I proposed a couple of weeks ago. I have a locking issue to
discuss.
The current code surrounds both read and write access to the VxWorks
global variable with an intLock() / intUnlock() pair. I have been
reviewing old tech-talk messages and don't see any justification for
this over and above "to protect against race conditions while copying
the value".
I think that we need to decide why we are locking access. Is it so
that tasks A and B can't interfere with each other, or is it so that
interrupt X can change a global variable safely? The current solution
addresses only the latter, because intLock() doesn't prevent task
switches (and indeed, if a task switch occurs, then interrupts will be
enabled while the new task is active; see the man page for intLock()). I
believe that a taskLock() / taskUnlock() pair would be more
appropriate.
Then there's the issue of which operations are in fact
uninterruptable. Am I right in assuming that char, short, int, long,
float and doubles are all going to be transferred uninterruptably
(except possibly for doubles on machines with soft floating point
support)? If so, locks should be necessary only for (a) all access to
strings and waveforms and (b) write access to bo/mbbo/mbboDirect when
using the new features to address specified bits (because there is a
read/mask/write cycle).
What I have done for now is to lock using _both_ intLock() _and_
taskLock(). The locking is _always_ done for write access (write access
is much rarer than read access, so the slight extra overhead of locking
even when it isn't necessary doesn't seem to be a problem), and is done
for read access only when reading strings and waveforms. I think that if
we can avoid locking for read access then we should do so (I don't like
the idea of all the intLock()s and/or taskLock()s which would otherwise
be occurring all the time with scanned records).
Maybe a semaphore would be better (using a single one would be
easiest; otherwise the device support would have to figure out which
records were addressing overlapping global variables)?
Comments are welcome.
William
PS, I noticed that some of the driver routines don't appear to protect
access to the hardware when performing read/mask/write operations.
For example, xy220_driver() doesn't seem to lock and so I think that
theoretically two tasks could interfere when writing bo, mbbo or
mbboDirect records associated with the same device.
- Replies:
- Re: locking and VxWorks global variable device support Ralph . Lange
- Navigate by Date:
- Prev:
Re: Python/CA Noboru Yamamoto
- Next:
Re: locking and VxWorks global variable device support Ralph . Lange
- 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: using vxWorks td() to shutdown CA clients and sequence tasks Jeff Hill
- Next:
Re: locking and VxWorks global variable device support Ralph . Lange
- 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
|