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: Some Channel Access Questions
From: Andrew Johnson <[email protected]>
To: [email protected]
Cc: Ben Franksen <[email protected]>
Date: Tue, 26 Oct 2010 17:33:56 -0500
Hi Ben,

I disagree with Jeff's response to this part of your question:

On Tuesday 26 October 2010 15:17:36 Ben Franksen wrote:
> combinations which will fail ("sorry, pv is active")? I remember
> reading some time ago that only one *db*_put_callback can be active at
> a time on a record (on the IOC), so will interleaving two
> ca_put_callbacks also fail?

He said there are no combinations that will fail, but he's wrong about the 
ca_put_callback() that you remember reading about, the operation can (and 
does) fail in some circumstances.

The IOC database can only have one putNotify operation active on a particular 
record at once.  The server side of a ca_put_callback() operation uses the 
IOC's putNotify mechanism to process the record and discover when the 
processing chain has completed, which is when it notifies the client.  If your 
first ca_put_callback() has not completed when the second one is processed, it 
will be rejected.  This requires that at least one of the records in the 
processing chain be asynchronous though.

If the processing chain is all synchronous then the record processing all 
takes place in the context of one of the RSRV (CA server) tasks.  In this case 
the putNotify completion will be called from the recGblFwdLink() processing of 
the last record in the chain, but still in the context of the RSRV thread, so 
the CA server can't start processing your second ca_put_callback() request 
until the first one has finished and there's no conflict between your two 
ca_put_callback() operations.

However that's not going to be true if there's any asynchronous processing 
involved.  In that case the putNotify can still be active when the process() 
operation requested by RSRV thread returns, so the server can try processing 
the second ca_put_callback() operation but it may be rejected.

Of course if the CA server you're talking to is not an IOC database then the 
behaviour you get depends on capabilities of the underlying server tool, which 
might perversely object to some other interleaving that the IOC database has 
no problems with.

HTH,

- Andrew
-- 
If a man is offered a fact which goes against his instincts, he will
scrutinize it closely, and unless the evidence is overwhelming, he will
refuse to believe it.  If, on the other hand, he is offered something
which affords a reason for acting in accordance to his instincts, he
will accept it even on the slightest evidence.  -- Bertrand Russell


Replies:
Re: Some Channel Access Questions Ben Franksen
RE: Some Channel Access Questions Jeff Hill
References:
Some Channel Access Questions Ben Franksen

Navigate by Date:
Prev: Re: Some Channel Access Questions Ben Franksen
Next: Re: Some Channel Access Questions Ben Franksen
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: Some Channel Access Questions Jeff Hill
Next: Re: Some Channel Access Questions Ben Franksen
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, 26 Oct 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·