Experimental Physics and Industrial Control System
> ben@sarun[3]: .../seq/work > time caput -c -w5 pvPutAsync1 1 &; sleep
> 1;
> time caput -c -w5 pvPutAsync2 1
> [1] 32140
> Old : pvPutAsync1 Low
> Old : pvPutAsync2 Low
> New : pvPutAsync2 High
> caput -c -w5 pvPutAsync2 1 0,00s user 0,01s system 22% cpu 0,036 total
> New : pvPutAsync1 Low
> caput -c -w5 pvPutAsync1 1 0,00s user 0,00s system 0% cpu 2,034 total
> [1] + done time caput -c -w5 pvPutAsync1 1
Since this is an issue with how the database is implemented I will let Andrew answer
Jeff
______________________________________________________
Jeffrey O. Hill Email [email protected]
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA FAX 505 665 5107
Message content: TSPA
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925
> -----Original Message-----
> From: [email protected] [mailto:tech-talk-
> [email protected]] On Behalf Of Ben Franksen
> Sent: Sunday, November 21, 2010 5:13 PM
> To: EPICS Techtalk
> Subject: ca_put_callback once again
>
> Hi Everyone
>
> I have made more experiments with ca_put_callback and discovered what I
> think is a serious bug.
>
> Imagine a CA client issuing a ca_put_callback and waiting for the
> callback. This might take a while because of asynchronous records being
> processed and waiting for their processing to complete. This processing
> can be caused either directly by the put, or indirectly (via forward or
> PP output links, maybe PP input links too). All this is documented in
> the Developer's Guide under putNotify. So far so good.
>
> Now imagine another ca_put_callback happens, which triggers processing
> of another network of records and this set overlaps with the first one
> above, while the first request is still in progress.
>
> What will happen? My original thought was that this might depend on
> whether the two calls come from the same client or from two different
> clients. This is not the case, however, except in the special case that
> both calls in fact target the same record. In this case, requests from
> the same client will be queued in the server, whereas requests from
> different clients behave as in the general case to which I come now.
>
> If the two calls target different records, but the processing chains
> (or
> networks) overlap, then what happens is that the second call
> *immediately* gets a *successful* callback.
>
> This is not what I expected. I had assumed that the CA server would
> send
> back an error to the second client, saying that there is already
> another request pending. Indeed, there is an error code in caerr.h,
> namely
>
> #define ECA_PUTCBINPROG DEFMSG(CA_K_ERROR, 45)
>
> that I assumed is there for this case. Not so.
>
> The problem is that this defeats the whole purpose of the
> ca_put_callback resp. putNotify which is to make sure that the
> processing really has completed. If another client, *any* client
> anywhere on the control network happens to issue a call that interferes
> with mine it might be that I get a success callback even though nothing
> has completed yet.
>
> This is a bug, IMO. If a client specifically asks for a callback to
> make
> sure something it wishes to happen in the server has actually happened,
> then the server must either wait for completion, however long it takes,
> or else respond with an error.
>
> BTW, the scenario can be easily tested, this is my test db file (which
> I
> run with 'softIoc -d <dbfile>'):
>
> record(bo,"pvPutAsync1") {
> field(ZNAM,"Low")
> field(ONAM,"High")
> field(HIGH,"1")
> field(OUT,"pvPutAsyncSeq.SELN PP")
> }
> record(bo,"pvPutAsync2") {
> field(ZNAM,"Low")
> field(ONAM,"High")
> field(HIGH,"1")
> field(OUT,"pvPutAsyncSeq.SELN PP")
> }
> record(seq,"pvPutAsyncSeq") {
> field(SELM,"Specified")
> field(DLY1,"2")
> field(DOL1,"1")
> field(LNK1,"pvPutAsyncRes CA")
> }
> record(longin,"pvPutAsyncRes") {
> }
>
> This is the test command line and the output:
>
> ben@sarun[3]: .../seq/work > time caput -c -w5 pvPutAsync1 1 &; sleep
> 1;
> time caput -c -w5 pvPutAsync2 1
> [1] 32140
> Old : pvPutAsync1 Low
> Old : pvPutAsync2 Low
> New : pvPutAsync2 High
> caput -c -w5 pvPutAsync2 1 0,00s user 0,01s system 22% cpu 0,036 total
> New : pvPutAsync1 Low
> caput -c -w5 pvPutAsync1 1 0,00s user 0,00s system 0% cpu 2,034 total
> [1] + done time caput -c -w5 pvPutAsync1 1
>
> I checked the code in caput.c to make sure that caput reports an error
> in the callback message. It does and as you can see there is no error
> reported. The test was run under 3.14.12-rc1 for the client (the -c
> switch is new), but tests with the sequencer indicate that it happens
> in 3.14.8.2, too.
>
> Cheers
> Ben
> --
> "Never confuse what is natural with what is habitual."
> -- attributed to Mahatma Gandhi
- References:
- ca_put_callback once again Ben Franksen
- Navigate by Date:
- Prev:
ca_put_callback once again Ben Franksen
- 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
- Navigate by Thread:
- Prev:
ca_put_callback once again Ben Franksen
- 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