On Mittwoch, 24. November 2010, Jeff Hill wrote:
> > It seems overly restrictive to include the whole lock-set, there
> > can be multiple non-overlapping putNotify groups within the same
> > lock-set since nowadays we do not allow an NPP+NMS link to break a
> > lock-set into two.
>
> What are the potential negatives of restricting only one put notify
> request to be active, while at the same time allowing several put
> notify requests to be pending initiation, within an entire lock set.
Remember that putNotify chain processing stops if a record is found
active, no matter whether this has been caused by another putNotify or
not. A general solution that queues putNotify requests must take this
into consideration.
Here is a possible solution that takes Andrews reservations about
re-initiating the whole putNotify (including all the intermediate
processing) into account:
Whenever putNotify finds an active record in the chain, instead of
cutting the processing chain short at this point as it does now, it
merely *suspends* itself. When the record in question completes its
processing (calling recGblFwdLink), it sees the suspended putNotify,
and *resumes* it, causing an immediate re-processing, so the putNotify
can continue. Timeout counters keep on running all the time
(figuratively speaking) so if all this takes too long, the putNotify
times out just as it does now.
Now, what if two independent putNotify requests are started at different
ends of a set of records, process towards one another and then collide,
each one waiting for a different record to become un-blocked? This
looks like a recipe for disaster (deadlock).
One way out is to restrict active putNotify requests to one per lockset,
as Jeff proposed, and queue any further ones. Another possibility is to
introduce "putNotify sets" (short: PN sets): each lock set is then a
disjoint union of PN sets; these would be connected by links that cause
processing, i.e. forward links and any input or output (DB) link with
the PP property. This would certainly complicate the implementation; it
is not clear to me whether it would be worth the price.
In a way such a solution would just automate what the user now has to
ensure manually anyway (without having any tool to support her), i.e.
serialize all putNotify requests to a set of records for which two
independent requests might possibly collide.
Cheers
Ben
- Replies:
- Re: ca_put_callback once again Andrew Johnson
- References:
- Re: ca_put_callback once again Tim Mooney
- Re: ca_put_callback once again Andrew Johnson
- RE: ca_put_callback once again Jeff Hill
- Navigate by Date:
- Prev:
EPICS Base 3.14.12 released. Andrew Johnson
- Next:
RE: EPICS Base 3.14.12 released. Jim Chen
- 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: ca_put_callback once again Jeff Hill
- Next:
Re: ca_put_callback once again Andrew Johnson
- 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
|