Experimental Physics and
Industrial Control System

[email protected] (William Lupton) · Tue, 25 Jan 2000 08:56:36 -1000

Thanks Ralph...

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

OK.

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

Ah... yes, well I hadn't thought it through, had I? The code within the
locked section is now more complex than it was but it's just switches
and masking and so on, nothing in the kernel.

Can we be absolutely _sure_ that no task switch can occur? What about a
multi-processor system or an autonomous board doing DMA straight into
memory for example? Still, taskLock() or a semaphore probably wouldn't
help there either.

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

OK. I'm happy that the VxWorks device support falls into the former
category and that intLock() will do the intended job in most if not
all realistic situations.

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

Yes, but the existing intLock() is locking out interrupts and therefore,
as you point out, non-preemptive task switches, so surely it is holding
things up for as long as a semaphore would?

>One semaphore per variable sounds more reasonable to me.

Well, I'm unwilling to invest the time in a general semaphore-based
solution for the VxWorks global variable support at this stage. Even
doing it by variable name doesn't cover the case (which I have used
extensively during testing) where several global pointers reference the
same memory location.

My proposal is simply to revert to the previous behavior of unconditional
intLock() / intUnlock() locking.

Thanks,

William

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System