Hi Marty.
Thanks for your response. Because I like discussions I appended some
more ideas that just crossed my mind...
Marty Kraimer wrote:
> Till,
>
> I think the following is the only issue still bothering you. Is this true?
>
yep.
> All records linked together are put in the same lock set (for the reason
> discussed in the App Dev Guide) EXCEPT for scalar NPP NMS input links.
>
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 exception was made just to prevent locks sets from becoming big just because
> one record of a lock set just want some relatively recent value from another
> record.
>
makes sense to me. I like the feature of a `leightweight' link.
>
> DBF_STRING should not have been included because strcpy is certainly not an
> atomic operation. I can also believe that on some architecture/compiler
> implementations copying some other types (such as doubles) may not be atomic.
>
IMHO, strings are the only problem. In order to atomically copy
`doubles' we might
get away by just disabling interrupts. Probably this does no harm for a
two word
copy operation. It could maybe even done transparently by the conversion
routines.
If string fields were just a (char*), the copy operation could be done
to a buffer
and
eventually the pointer changed atomically to point to the new string.
E.g. in case of the stringinRecord: If `val' was just a char*, there
would be
the buffers nval and oval. Record processing copies nval to oval , sets
val to
point to oval and asks device support to update nval. Evantually, val
(atomically)
is set to point to nval again. Hence, val always points to a valid
string.
Alternatively, there could be mutexes (associated with a field, record,
lockset or
allocated as needed from a pool...) that should be taken before
accessing nonscalar
record fields providing a finer grained record field locking.
>
> In defense of the decision please note that when lock sets were first
> implemented
>
> 1) vxWorks did not support recursive locking (semMcreate)
Must have been hard times :-)
>
> Because 2) now exists it may be a good idea to get rid of the input NPP NMS
> exception and treat all links the same when determining lock sets, i.e. all
> records linked via database links are put in the same lock set.
Maybe a new option could be added to flag if the target should be
locked?
IMHO, the easiest solution for the moment would be disabling interrupts
while copying doubles (conversion routines) and treating DBF_STRING
as nonscalar.
As I said, these are just humble ideas of my paranoid brain ;-)
Best regards.
Till Straumann.
- Replies:
- Re: database race condition? Marty Kraimer
- References:
- database race condition? Till Straumann
- Re: database race condition? Marty Kraimer
- Navigate by Date:
- Prev:
Re: Scan Record Mark J. Ryan
- Next:
Re: EPICS web pages at LANL Ralph Lange
- 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? Marty Kraimer
- Next:
Re: database race condition? Marty Kraimer
- 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
|