EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: ca_put_callback once again
From: Ben Franksen <[email protected]>
To: [email protected]
Date: Wed, 24 Nov 2010 23:44:57 +0100
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  <20102011  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  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 29 Nov 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·