Experimental Physics and
Industrial Control System

[email protected] · Tue, 25 Jan 2000 12:12:34 +0100 (MET)

William,

here's some comments...

  > 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?

Both! You never know if the user has a task and/or an ISR running that
tries to change or read the variable.

  > 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.

Well, intLock() blocks out the timer interrupt, so preemptive task
switches will not occur. The only way to still mess around is calling
kernel services within a pair of intLock()/intUnlock().

So for a small block of critical code which doesn't call vxWorks
routines and doesn't access off CPU board hardware I would use intLock()
because it is VERY fast and safe (in this case).

Larger, more complex blocks should IMHO be guarded by semaphores to make
the mechanism work from both interrupt and task level. Semaphores may be
a bit slower than taskLock()/taskUnlock() that only sets a field in the
vxWorks task control block, though.

With semaphores you have the problem that the device support and the
external user task / ISR have to somehow agree on the semaphore to
use. Maybe using a named semaphore with the variable name in it would do?

  > 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)?

On all target architectures and all boards? What if the variable is
mapped to a piggy back memory module? Or to a VME address?

Should there be a record field that specifies the desired type of
locking (None / Local / Semaphore)?

None      = No locking at all        for atomic local variables
Local     = intLock()/intUnlock()    for small non-atomic local variables
Semaphore = Named Semaphore locking  for large or VME based variables

  > 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).

In terms of cpu time intLock()s are next to nothing (it is used in quite
a few places in iocCore already). Reading junk because the writer
interrupted may be much worse.

  > 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)?

You mean a single semaphore for _all_ accessible vxWorks variables on an
IOC? I guess this would hold up things far too long if you have multiple
large waveforms in an IOC.

One semaphore per variable sounds more reasonable to me.

Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System