EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: database race condition?
From: Marty Kraimer <[email protected]>
To: Till Straumann <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Tue, 23 Mar 1999 08:06:40 -0600
Till Straumann wrote:
> 
> Marty Kraimer wrote:
> 
> > The Application Developer's Guide states:
> >
> > "Lock sets prevent two different tasks from simultaneously modifying records in
> > the same lock set."
> >
> > This allows algorithms to be developed via linked records with the guarantee
> > that outside tasks, e.g. a CA server, will not modify something in the lock set
> > while the algorithm is being executed. Fine grained locks do not provide this
> > guarantee.
> >
> 
> Well, this guarantee is not needed if we just want to atomically read a
> (possibly old) value (read a NPP NMS link) and therefore we could get
> away without locking a whole set (and possibly blocking the task that
> just wants to read the link in question for a much longer time than needed).
> But what we need is the guarantee that the value is not modified while
> it is read by another task. I was just brainstorming how this could be done
> with minimal changes.
> 
> Till.

I am also brainstromming.

Is this necessary?

What type of task needs this type of priority?

If it is one of the scan tasks getting/putting links then using CA solves the
problem. The task will never delay for CA links because another task handles the
I/O and keeps private copies of the data for each link.

If it is a sequence or ca task then they are fighting amoung themselves. The
priorities have been set to give the scan tasks higher priority than sequence
tasks and sequence tasks higher priority than CA. The only time a task of this
type can delay other tasks for a significent period of time is if a put results
in many records being processed. This presents the same problem as a low
priority scan task doing a put that causes higher priority scan tasks to wait
because it access records in the same lock set.

If each get/put is locked in addition to locking the lock set then database
access must also lock each get/put. On an mv167 it taks about 50 microseconds to
process a soft ai records which fetches a value from another record via a
DB_LINK. It takes several microseconds (I cant remember the number but I think
it was something like 5) to do a semTake,semGive. Thus it is a significent cpu
overhead to lock each get/put.

Marty Kraimer

Replies:
Re: database race condition? Till Straumann
References:
database race condition? Till Straumann
Re: database race condition? Marty Kraimer
Re: database race condition? Till Straumann
Re: database race condition? Marty Kraimer
Re: database race condition? Till Straumann

Navigate by Date:
Prev: Re: database race condition? Till Straumann
Next: Time Stamping Natalie Otey
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: database race condition? Till Straumann
Next: Re: database race condition? Till Straumann
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·