Experimental Physics and Industrial Control System
|
Subject: |
Re: Dynamic Loading and Unloading of EPICS Device Support and Record. |
From: |
Marty Kraimer <[email protected]> |
To: |
Core-Talk <[email protected]> |
Date: |
Wed, 08 Sep 2010 15:06:04 -0400 |
On 09/08/2010 01:44 PM, Dalesio, Leo wrote:
RE: Dynamic Loading and Unloading of EPICS Device Support
and Record.
Marty should chime in here too.
There were two large issues with dynamically adding records -
1) recomputing the lock sets - which was handled when
modifying database links was implemented.
2) I believe was the record initialization and device support
initialization issues. To be clear on this, it would be best
to read through the record type and instance initialization,
the device type and device instance initialization, and the
driver initialization. Most likely, existing device and driver
support would need to be reworked. For a while, I would just
not write an initialization routine and take care of that in
the read or write. That way I knew it could be done at any
time.
I would not delete records. This really opens a can of worms.
It would be more straight forward to disable them. Create a
new alarm severity - disabled. Then the action to take on
disabled can be configured. No channel access to it through
access security rules for instance.
The deletion is more complex, as references to that record
within an IOC, resolve to the memory location to improve the
performance. A record does not know everyone that refers to
it. To further complicate things, there are also state
programs that would have to deal with records going away.
Currently they support channel access disconnects - so perhaps
this is not as difficult as I think.
In any case - start with being able to add them dynamically.
If that goes well and you're feeling brave - then go for
delete second.
-
Let me explain briefly how the javaIOC handles
dynamic creation and deletion of database records.
Rather than lock sets each javaIOC record is locked. To handle
links between records it is possible to lock one additional record
besides the currently locked record. The implementation prevents
deadlocks.
In addition any code that accesses a record must register itself
by supplying a callback method named "detach".
Each record instance has a RecordProcess created for it.
RecordProcess calls the top level Support which must exist. Each
field can optionally also have a Support.
RecordProccess and Support implement the following methods:
initialize, start,process, stop, and uninitialize. When initialize
is called the support can create anything it requires for
processing but can not access anything outside the record. Start
can connect to things outside the record, e.g. hardware, other
records, channel access, etc. Process is called when a record is
processed. Stop undoes start. Uninitialize undoes initialize.
There are two databases involved with records that can be
processed: master, and beingInstalled.
The following is done to delete a record: The record is removed
from the master database. The detach method of all registered code
is called. After detach is called the code must no longer access
the record. Then RecordProcess.stop() is called. This results in
all Support.stop() methods being called, Then
RecordProcess.uninitialize is called which again results in all
the Support.uninitialize methods being called. After this the
record is gone.
To add a record, actually a set of records, the following is done:
The records are added to the beingInstalled database. For each
record the following is done: Look for all fields that have a
request to replace the current PVField implementation. Ceates a
RecordProcess for the the record and create the Support for all
fields that have support. Then call RecordProcess.initialize and
then RecordProcess.start,. If anything fails during this install
quits. If all succeed then the beingInstalled records are moved to
the master database. It is somewhat more complicated than this but
not much.
The really big problems with the v3 IOC are: 1) lock sets, which
span records, and 2) There is no equivalent in record support or
device support to stop and initialize, and 3) There is no
equivalent to detach.
For lock sets I think it means the entire database must be locked
while a record is added or deleted so that lock sets can be
recomputed. There is already a global lock for the database which
gets locked if a new access security file is loaded into a running
IOC. I think I am remembering this correctly. But it does mean the
entire database must be locked which makes everything freeze.
To support stop and unintialize all record/device code for any
record to be added or deleted must be upgraded. In addition any
code that accesses record instances must register and provide a
detach method.
Sounds like a really big job.
As Bob says you could decide not to support record
deletion. That removes the need to support stop and uninitialize
and detach. That simplifies what must be done. But lock sets
still appear to be a problem.
I would still go with the idea of a
beingInstalled database. One thing to remember, however, is that
code that accesses other records (dbliink calink) must look in
both master and beingInstalled when looking for local records.
|
- Replies:
- Re: Dynamic Loading and Unloading of EPICS Device Support and Record. Andrew Johnson
- RE: Dynamic Loading and Unloading of EPICS Device Support and Record. Dalesio, Leo
- References:
- Dynamic Loading and Unloading of EPICS Device Support and Record. Ernest L. Williams Jr.
- Re: Dynamic Loading and Unloading of EPICS Device Support and Record. Andrew Johnson
- RE: Dynamic Loading and Unloading of EPICS Device Support and Record. Geng, Zheqiao
- RE: Dynamic Loading and Unloading of EPICS Device Support and Record. Dalesio, Leo
- Navigate by Date:
- Prev:
RE: Dynamic Loading and Unloading of EPICS Device Support and Record. Dalesio, Leo
- Next:
Re: Dynamic Loading and Unloading of EPICS Device Support and Record. Andrew Johnson
- 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: Dynamic Loading and Unloading of EPICS Device Support and Record. Dalesio, Leo
- Next:
Re: Dynamic Loading and Unloading of EPICS Device Support and Record. Andrew Johnson
- 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
·
|