EPICS Home

Experimental Physics and Industrial Control System


 
2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
<== Date ==> <== Thread ==>

Subject: Re: EPICS base V4
From: Andrew Johnson <[email protected]>
To: Marty Kraimer <[email protected]>
Cc: Benjamin Franksen <[email protected]>, Eric Norum <[email protected]>, Jeff Hill <[email protected]>, Ralph Lange <[email protected]>, Bob Dalesio <[email protected]>, Ned Arnold <[email protected]>, Matej Sekoranja <[email protected]>
Date: Wed, 23 Feb 2005 17:52:07 -0600
Proposal for V4:

Change the way in which records are executed, allowing the database designer to select which threads perform processing of particular sets of records.
In V3 we create a thread for each scan period, plus a number of other
threads for callbacks etc. so the thread that a record processes in is
vaguely related to its SCAN and PRIO fields. I propose changing
menuScan so it only contains "Passive", "Event", "I/O Interrupt" and
"Periodic". We add another field which is a double called scanPeriod
which can be set to any period in seconds (this two-field approach is
analagous to "Event" and the old EVNT field). We use a series of
epicsTimerQueues or something similar to cause records to be processed
when the relevent time interval has elapsed since they were last run.
Now instead of having a thread for each period, we change the PRIO field
(whcih is currently only used for Event and I/O Interrupt) into a field
called scanThread. This is a menu field which selects which thread
actually does the record processing (executes the epicsTimerQueue), and
this allows the database designer much more control over the relative
priorities of different parts of the IOC's database.
I suspect this would probably increase the number of threads that
actually get used, but it makes it possible to partition off different
parts of the database so that the highest priority work always gets done
even though there's a frequently processed chain going on in some lower
priority thread. We would not need the callback tasks that currently do
I/O Interrupt processing, because the interrupt can just add the record
into the queue for its regular processing thread.
Note that a record which has scan=Passive should still be executed by
the thread of whichever record processes it (FLNK, PP link), although we
could add another choice ("Triggered") where the record's selected
scanThread gets used. Hmm, that has implications for providing a PV-Get
that can cross a thread boundary, making the Getting record wait for the
other to return the desired value... I haven't thought about this part
properly yet, it has implications for semaphores and deadlocks.
Comments?

- Andrew
--
Dear God, I didn't think orange went with purple until I saw
the sunset you made last night.  That was really cool. - Caro



Replies:
Re: EPICS base V4 Benjamin Franksen
Re: EPICS base V4 Ralph Lange
References:
Re: EPICS base V4: iocCore database Marty Kraimer
Re: EPICS base V4: iocCore database Andrew Johnson
Re: EPICS base V4: iocCore database: Booleans Benjamin Franksen
EPICS base V4 Marty Kraimer

Navigate by Date:
Prev: Re: [Fwd: RE: EPICS base V4: iocCore database] Benjamin Franksen
Next: Re: EPICS base V4 Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
Navigate by Thread:
Prev: RE: EPICS base V4 Jeff Hill
Next: Re: EPICS base V4 Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022