Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 29 Jan 2009 16:07:55 -0600

Hi Babak,

On Thursday 29 January 2009 07:30:30 Kalantari Babak wrote:
>
> Regarding the problem you mentioned (database locks) before:
>
> What if the "recordGenerator" record creates a new "dbbase" which is a
> copy of the original "dbbase"?
>
> That is, to maintain two "dbbase" in parallel: say "dbbase" and
> "dbbaseCopy". The creation (with dbAllocBase()) of "dbbaseCopy" is done
> at record init. Whenever the record-process routine gets called, it
> first copies content of "dbbase" to "dbbaseCopy" and from this point on
> it works on this copy (to generate a new record instance). When this
> activity is finished then we exchange these two pointers just before
> returning from process.
>
> What problems do you see with this approach? (memory usage? etc.??)

dbbase only holds static database information, it doesn't know anything about 
the database runtime structures which also point into it.  Once iocInit has 
been executed there are many background tasks running which maintain private 
lists of all kinds that have pointers to record instances etc.  You therefore 
cannot make a complete copy of the database down to the record level and 
expect to switch to it like you described (you really wouldn't want to try 
either, given the number of internal pointers that a running IOC keeps).

I suspect the simplest way to make it possible to "create" new records at 
runtime will be to actually create aliases to records allocated from a pool 
of spares that were loaded before iocInit.  I added alias support to the CVS 
version of Base fairly recently; aliases look like a regular record from the 
outside, the only detectable difference is if you ask for the .NAME field of 
one you'll get its canonical name rather than the alias name.

At present it isn't safe to create aliases after iocInit because the process 
variable directory (a hash table that maps record names to their record 
pointers) doesn't have any locks in it.  That means a CA client thread could 
be searching for a PV in a hash bucket at the same time that the alias is 
being inserted into that bucket, with the possibility of nasty results.

I believe though that I could add a mutex to each hash bucket and if needed to 
the dbRecordType without major lock contention, and the result should then be 
safe.  The added locks would slow down iocInit and the CA name resolution 
process a little, and there's also a slight risk that this could create a 
deadlock in some circumstances.  This change might also make it possible to 
rename the existing record rather than having to create an alias to it, but 
that prospect makes me a little uneasy.

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harold Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System