Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 22 Nov 2010 09:42:13 -0700

> 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System