Re: dbcar() and dbcaStats() locking

[Andrew Johnson <anj@aps.anl.gov>]

Hi Ralph,

On 08/08/2014 02:08 PM, Ralph Lange wrote:
> I am not afraid of miscounting at all...
> 
> My impression was dbcar() takes the lock to avoid a situation where
> another thread is changing the CA link into a DB or CONSTANT link
> while the investigation of CA properties is going on. The pointer to
> the cid would suddenly be invalid, and the ca_... functions that are
> dereferencing the pointer could easily segfault.

Looking at dbCaRemoveLink() the pca structure is still valid after the
statement plink->value.pv_link.pvt = 0; it gets queued up for the
dbCaTask() to call ca_clear_channel(pca->chid) which will happen at a
lower priority than the periodic scan task that normally calls
dbcaStats(). This means it should be safe on UP systems with priority
scheduling. Lightly loaded SMP systems may be a different matter though...

> In any case I don't see the justification for handling the cases
> different.

dbcar is a user command, so is run very infrequently and on demand only.
It can afford to delay the IOC slightly if this is necessary to prevent
problems in generating its output for the user.

Here at the APS dbcaStats() gets called every 30 seconds on every IOC to
update its $(IOC):dbcaCount and $(IOC):dbcaDisco status PVs (we have
similar PVs for calls to ascaStats() and seqcaStats()). I didn't want to
take a global lock in that circumstance, although I can see the
potential for the current code to cause a problem in some circumstances.

The dbCaTask already has a chan_count variable that could be turned into
an atomic variable, and adding a similar connection counter should be
relatively easy. Codeathon task for someone?

- Andrew
-- 
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock