Experimental Physics and Industrial Control System
|
I like these ideas.
Does this imply that IOC load is evenly distributed? I.e. that records
with the same scanPeriod period are processed in a "spread over time"
manner rather than "en bloc" as in V3?
I would prefer such a spread behaviour, as it really should result in a
more "elastic" IOC behavior. But: How would overload situations be
handled (i.e. processing all records with a certain scanPeriod takes
longer than that period). While the V3 method was inherently stable, it
might be that this new way requires additional care. (When spread over
different threads, overload situations may be hard to detect.)
The V3 mechanism of the PHAS field determining the order of processing
within a scan period does not make sense anymore with your approach,
right? Will we have to have some kind of replacement for that mechanism,
or can we urge the user to go to hard links and events (yes: named
events!) instead?
Ralph
Andrew Johnson wrote:
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
- Replies:
- Re: EPICS base V4 Bob Dalesio
- Re: EPICS base V4 Andrew Johnson
- 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
- Re: EPICS base V4 Andrew Johnson
- Navigate by Date:
- Prev:
RE: memory management Jeff Hill
- Next:
Re: EPICS base V4 Bob Dalesio
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: EPICS base V4 Benjamin Franksen
- Next:
Re: EPICS base V4 Bob Dalesio
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|