Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: EPICS base V4
From: Andrew Johnson <anj@aps.anl.gov>
To: Marty Kraimer <mrk@aps.anl.gov>
Cc: Benjamin Franksen <benjamin.franksen@bessy.de>, Eric Norum <norume@aps.anl.gov>, Jeff Hill <johill@lanl.gov>, Ralph Lange <Ralph.Lange@mail.bessy.de>, Bob Dalesio <bdalesio1@comcast.net>, Ned Arnold <nda@aps.anl.gov>, Matej Sekoranja <matej.sekoranja@ijs.si>
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 
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 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·