EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: recordGenerator record
From: Andrew Johnson <[email protected]>
To: [email protected]
Cc: Kalantari Babak <[email protected]>
Date: Fri, 24 Oct 2008 11:10:29 -0500
Hi Babak,

On Friday 24 October 2008 08:56:21 Kalantari Babak wrote:
>
> I have spent some time on writing a new EPICS record type which can
> create new record instances at IOC runtime. At the moment the code is in
> very preliminary level but it works. "It works" means I am able to
> generate instances of almost any record types at IOC runtime. The
> behavior is as the following:
>
> 1. User specifies record type e.g. "ao", "calc", etc. by CA/DB-write to
> a field of "recordGenerator" record
>
> 2. User specifies the channel name by CA/DB-write to a field of
> "recordGenerator" record
>
> - As a result a channel with soft device support (soft channel) with
> corresponding type and name is generated.

Unfortunately there are major problems with doing this in a running IOC: we 
don't have locks in all the database structures that need to be modified when 
a new record instance is created, which makes this a precarious activity.  
The current dbStaticLib design assumes that all record creation happens while 
the IOC is running single-threaded before initialization of any scan or 
server threads.  For example, the pdbbase->ppvd structure which is a hash 
table of all the record instances has no locks, so one or more server threads 
could be searching for PV names in the hash bucket linked list that your new 
record instance gets added to.

Looking at the code in base/src/dbStatic/dbPvdLib.c I can see several ways 
that simultaneous calls to dbPvdFind() and dbPvdAdd() in different threads 
could cause a segfault, because this code has not been written with that 
possibility in mind.

Note that remediation of this by adding locks to the pdbbase->ppvd structure 
is not as easy as it might seem because we have to check for deadlocks with 
other parts of the system which already have locks in place, and also because 
of the effect such locks could have on PV search performance (which IOCs do a 
lot of and which dbPvdFind() is currently optimized for).

> One potential usage of this may be to have (soft) waveform records which
> can have changeable size. One way to do this is to copy the content of
> the generated waveform record, then delete existing record and generate
> another one with the new size and fill it in with the data copied from
> the previous waveform.

Deletion of a record from an active database is a *much* harder thing than 
adding one, because there are many places that might have a pointer to your 
record instance, and you have to find them *all* before you can safely free 
the record.

If you want to be able to re-size a waveform record, it would be much better 
and easier to modify the record type to support that directly.  You'd have to 
ensure that the CA server doesn't still have a pointer to the old data 
somewhere, but I don't think that would be an insurmountable problem.

> 1. are there any interests (now/in future) in such a record type, in
> another word, is it worth at all to put efforts for such thing?

The ability to create new record instances has been on our to-do list for a 
long time, but nobody has tried to work on it recently that I know of.  That 
says two things:  1: Yes, we'd really like to be able to do it, but 2: it's 
not going to be an easy thing to do properly.

> 2. (if yes) what features such record type can/must have?

I would start by concentrating on the underlying ability of dbStaticLib to 
create new records while the IOC is running.  Putting a record type API on 
top of this is the easy part, once the dbStaticLib code can do so safely.

Sorry to burst your balloon...

- Andrew
-- 
Talk is cheap. Show me the code. -- Linus Torvalds

Replies:
Re: recordGenerator record Dirk Zimoch
References:
recordGenerator record Kalantari Babak

Navigate by Date:
Prev: Re: recordGenerator record Ned Arnold
Next: areaDetector R1-2 released Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: recordGenerator record Ned Arnold
Next: Re: recordGenerator record Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·