Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 3 Jul 2013 01:22:41 +0200

Am Mittwoch, 19. Juni 2013, 18:10:32 schrieb Benjamin Franksen:
> On Wednesday, June 12, 2013 12:38:40 J. Lewis Muir wrote:
> > On 6/12/13 11:10 AM, Benjamin Franksen wrote:
> > > On Monday, June 10, 2013 17:22:12 Carl Lionberger wrote:
> > >> Looking at the code in seq_ca.c and seq_if.c, it seems that if a
> > >> synchronous pvGet ever fails to get a callback from channel access,
> > >> the "get completion timeout" message is set in the channel metadata
> > >> and all subsequent attempts to do pvGets on that channel will fail as
> > >> in the first
> > >> message.  The latter occurs because there is a get semaphore for each
> > >> channel that the callback is supposed to give.
> > >>
> > >> My thought is that if the callback doesn't come the semaphore should
> > >> be released in the same code that sets the "get completion timeout"
> > >> message.
> > >
> > > I find it very hard to judge what the correct behaviour is, here.
> >
> > I think I've run into Carl's problem before too.
> >
> > Could you supply the CA callback with a sequence number that would
> > uniquely identify the callback as being for a particular pvGet?  This
> > way, you could ignore a callback if it arrives for a pvGet that has been
> > abandoned.

I just found that fixing this is more subtle than I expected.

The problem is this: in order to be able to associate incoming put and get
events (callbacks from CA) to where the request originated, I need two pieces
of information:

(a) the variable
(b) the state set (~= thread)

Both pieces are identified via pointers. So I had to introduce a data type for
requests (a struct) that contains just these two pointers. I pass a pointer to
such a struct to ca_array_get_callback resp. ca_array_put_callback, which when
they call the callback, pass the pointer as an argument.

This pointer MUST be valid until I receive the callback that belongs to the
request! Because if not, then the callback routine accesses invalid memory,
leading to crashes or worse.

That means I must never call free (actually freeListFree, but that's not
important here) before the callback arrives. But what if it never arrives?
Then we get a memory leak. Arrgh!

This leads me to the following

Channel Access Question
=======================

Does the CA client library guarantee that callbacks for ca_array_get_callback
and ca_array_put_callback are eventually called, no matter what, assuming I
just wait long enough?

Note that "no matter what" includes lost connections etc.

If I can rely on all put/get request callbacks to be called, eventually, then
I can solve the (original) problem by using the request pointer as my unique
identifier. I'll have to store the request pointers, (quasi-) statically
allocating memory for (number of state sets)x(number of assigned variables)
request pointers, but taht's no different from storing the same amount of
semaphores which I already do. And I simply forget about timed out requests,
assuming that my callback will eventually be called and the memory freed.

If I cannot rely on this, then I have to keep track of timed out requests
(probably chaining them in a list), so that at least the disconnect handler
can finally free them. (That assumes that I *can* rely on the connection
handler to be called, eventually.)

Another solution would be to avoid allocation of request structs by pressing
the information I need into an integer and casting that from/to the void
pointer. This means that on 32 bit systems I have to introduce upper limits
(2^16 ) for the number of variables and the number of state sets per program.
The limits themselves are not unreasonable, but I would rather try to avoid
such an ugly hack.

All this headache could easily be avoided if the CA client API offered a way
to cancel pending requests.

Cheers
--
Ben Franksen
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachm€nts

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System