Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Fri, 08 Aug 2014 14:14:15 -0400

Andrew/Ralph,

Please let me know if you're planning to make any significant changes to
dbcar().  My present work on lock sets will force some changes as
dbLockSetGblLock() goes away, and I don't want to duplicate efforts.

Michael

On 08/08/2014 12:13 PM, Andrew Johnson wrote:
> Hi Ralph,
> 
> On 08/08/2014 10:19 AM, Ralph Lange wrote:
>> I was looking at db/dbCaTest.c today, and I found that
>> 
>> dbcar() is looping through all record instances of all types, and taking
>> dbLockSetGblLock() when investigating a CA link.
>> dbcaStats() is looping through all record instances of all types, and
>> *NOT* taking dbLockSetGblLock() when investigating a CA link.
>> 
>> Why? Why not?
>> 
>> dbcar() is doing more CA investigation, and using the formatter in-between.
>> But other than that, dbcaStats() could also encounter another thread
>> changing the link type from CA to DB or CONSTANT.
> 
> As the guilty party my reasoning probably went something like this:
> Links don't get changed very often; if a change does occur at the moment
> when we are counting a specific link, the result is that the statistics
> could be off by one that one time, but the consequence of that
> miss-count is effectively nil — the number was changing at the time
> anyway, so is really wrong? The user would only really notice if the
> number of CA links gets counted as less than the number of connected
> links, resulting in *pdiscon < 0.
> 
>> Can anyone explain why these similar cases are handled differently?
> 
> I didn't want to lock the global lock every time we redo the statistics
> count (which happens frequently if you're running devIocStats) as that
> could affect IOC performance.
> 
> A better implementation might keep separate (atomic) running counter
> variables inside dbCa.c and have dbcaStats just return the values from
> those counters. dbcar could compare its counts with those (it still has
> to scan the whole database anyway). Using atomic counters wouldn't
> prevent dbcaStats from returning *pdiscon < 0 though, we'd need a single
> lock to cover both counters to prevent that.
> 
> HTH,
> 
> - Andrew
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System