Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 18 Jul 2011 10:57:25 -0500

Hi Michael,

On 2011-07-18 [email protected] wrote:
> 
> the entire purpose of
> wait_for_epics_ready() is to ensure I can generate I/O Intr events without
> losing them.  I wonder whether I should use initHookAfterInterruptAccept
> instead ... don't suppose it makes much difference.

It sounds like your interrupt routine should just be checking interruptAccept 
and only generating I/O Intr events when it sees it true.

> On the other hand, I do have two problems with this:
> 
> 1. Polling?  Eww.  In my particular example I guess it doesn't hugely
>  matter, but it makes me queasy in general.

While I don't particularly like the use of the interruptAccept variable 
because it's not strictly SMP-safe, that's how the original design worked and 
it doesn't seem too easy to change — it is used a lot in device support.  On 
vxWorks at least it's often called from interrupt context where we can't use 
semTake() or epicsMutexLock(), so we'd have to use a not-yet-available 
epicsAtomic API to replace it (which could then be done with a suitable 
macro).

> I see that there's a scanPause() function which can reset interruptAccept
>  -- when does this get called?  I hope this isn't called normally! 
>  (Scrabbling through the code suggests this is only called by iocPause(),
>  which is just a command line debug hack, not for normal use, I hope...)

Ralph has explained why it's there; your "normal use" may not be the same as 
someone else's, but that is a published IOC command and API (see iocInit.h).  
To know exactly what the state of the IOC is you should listen for both 
initHookAfterDatabaseRunning (equivalent to initHookAfterInterruptAccept but 
which can occur more than once if someone calls iocPause and then iocRun) and 
initHookAfterCaServerPaused, and have former start and the latter stop your 
interrupt generation.  However since this exactly is what interruptAccept is 
for it's much easier to just use that...

Broadcast events are tricky on vxWorks, to do them properly (taking account of 
the priorities of all the waiting threads etc.) really requires implementing 
them inside the kernel.  I think that's why we haven't provided an osi API for 
them in libCom.

BTW, your wait_for_epics_ready() routine doesn't need to call malloc() [which 
is worth avoiding on vxWorks < 6.x for memory fragmentation reasons], it could 
allocate the waiter object on the stack since it's not going to return until 
after the object has been de-queued anyway.

- Andrew
-- 
Optimization is the process of taking something that works and
replacing it with something that almost works, but costs less.
-- Roger Needham

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System