2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== 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