g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  Index 1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014 
<== Date ==> <== Thread ==>

Subject: locking and VxWorks global variable device support
From: wlupton@keck.hawaii.edu (William Lupton)
To: tech-talk@aps.anl.gov
Date: Mon, 24 Jan 2000 17:45:53 -1000
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  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014 
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  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·