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
<1999>
2000
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
<1999>
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|