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: Till Straumann <[email protected]>
To: "[email protected]" <[email protected]>
Date: Mon, 22 Mar 1999 16:43:44 +0100
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  <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? Marty Kraimer
Next: Re: database race condition? Marty Kraimer
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 ·