Till Straumann wrote:
>
> Hi Marty.
>
> Thanks for your response. Because I like discussions I appended some
> more ideas that just crossed my mind...
> The only thing I didn't know was that there's nothing implemented like
> `atomic field access' in EPICS, so if I need mutual exclusion I have to
> put the whole records in one lock set.
> BTW, knowing this, there's nothing too bad about it (except maybe
> efficiency;
> a finer grained or `one writer, many readers' type locking scheme could
> maybe
> proposed for version 5.0 :-) ...) since the database designer usually
> can hack
> around this by reading DBF_STRING typed links MS if necessary.
> Still - the idea of having atomic access to record fields without
> needing to
> lock a whole set of records would be nice.
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.
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
- Navigate by Date:
- Prev:
Re: EPICS web pages at LANL Bill McDowell
- Next:
Re: Scan Record Tim Mooney
- 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
|