EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: dbcar() and dbcaStats() locking
From: Andrew Johnson <[email protected]>
To: <[email protected]>
Date: Fri, 8 Aug 2014 11:13:08 -0500
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
-- 
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock

Replies:
Re: dbcar() and dbcaStats() locking Michael Davidsaver
Re: dbcar() and dbcaStats() locking Ralph Lange
References:
dbcar() and dbcaStats() locking Ralph Lange

Navigate by Date:
Prev: dbcar() and dbcaStats() locking Ralph Lange
Next: Re: dbcar() and dbcaStats() locking Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: dbcar() and dbcaStats() locking Ralph Lange
Next: Re: dbcar() and dbcaStats() locking Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 08 Aug 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·