Experimental Physics and
Industrial Control System

Tim Mooney <[email protected]> · Fri, 28 Jan 2011 17:53:00 -0600 (CST)

No.  In the best case, you call ca_clear_channel() and then
free pUserPrivate.

Probably Jeff Hill can just tell us if it's possible for a sent
monitor (or other callback) to arrive after ca_clear_channel() has
been called.

You could test to see if it's possible, by modifying your
cleanup routine to change *pUserPrivate after calling
ca_clear_channel(), instead of freeing the pointer.  Then cause
value changes to the monitored PV at a high rate (preferably the
PV is in a different IOC), and call cleanup().  If your callback
routine ever sees the value of *pUserPrivate that you wrote in
cleanup(), you know it's possible.  You might have to do this many
many times, though, before you hit the time window in which a problem
occurs. It's worth the effort, though, because problems like this that
are hard to reproduce are many times more frustrating in a deployed
system than they are in a development system. 

Tim

----- Original Message -----
From: [email protected]
To: "Tim Mooney" <[email protected]>
Cc: [email protected]
Sent: Friday, January 28, 2011 5:09:44 PM
Subject: Re: ca_create_channel memory management

So in the best case scenario, I could just call ca_clear_channel after I
free pUserPrivate? Is there a way to determine if the worst case scenario
exists? If it does, is there anyway to fix or avoid it?

> Yes.  I'm worried about monitor (and other) callbacks that are
> in transit while the channel is being cleared.
>
> However, in the cases in which I needed to worry about this there was
> a software layer between the decision to clear the channel and the
> actual call to ca_clear_channel().  It may be that channel access
> somehow claws back sent monitors when a channel is cleared, but that
> has never been my understanding of how it works.  If it does work that
> way, all that I would worry about is that you're freeing pUserPrivate
> before calling ca_clear_channel(), thus opening a tiny time window in
> which a race condition is possible.
>
> Tim
>
> ----- Original Message -----
> From: [email protected]
> To: "Tim Mooney" <[email protected]>
> Sent: Friday, January 28, 2011 3:04:41 PM
> Subject: Re: ca_create_channel memory management
>
> Do you mean calls to the monitor callback function that have occurred
> prior to calling ca_clear_channel, but that somehow have not been
> processed?
>
>> I thought that ca_clear_channel took care of that? From the ca reference
>> manual:
>>
>> Clearing a channel does not cause its disconnect handler to be called,
>> but
>> clearing a channel does shutdown and reclaim any channel state change
>> event subscriptions (monitors) registered with the channel.
>>
>> Thank you,
>> Patrick
>>
>>> If your channel is doing any callbacks (e.g., you're monitoring it),
>>> you might have outstanding monitors at the time you decide to clear
>>> the channel.  You need to tell your callback routine to ignore any
>>> calls that come after you've called cleanup(), so it doesn't reference
>>> pUserPrivate after it's been freed.
>>> Tim
>>>
>>> ----- Original Message -----
>>>> From: [email protected]
>>>> To: "Andrew Johnson" <[email protected]>
>>>> Cc: [email protected]
>>>> Sent: Friday, January 28, 2011 11:56:37 AM
>>>> Subject: Re: ca_create_channel memory management
>>>> So:
>>>>
>>>> void cleanup(chid ChanID) {
>>>> void* pUserPrivate;
>>>>
>>>> pUserPrivate = ca_puser(ChanID);
>>>> free(pUserPrivate);
>>>> ca_clear_channel(ChanID);
>>>> }
>>>> ?
>>>>
>>>> > Hi Patrick,
>>>> >
>>>> > On Friday 28 January 2011 11:10:29 [email protected]
>>>> > wrote:
>>>> >> If you allocate memory and send a pointer to it in the puser field
>>>> >> of
>>>> >> ca_create_channel, does it get freed when ca_clear_channel is
>>>> >> called, or
>>>> >> should I do that explicitly?
>>>> >
>>>> > There's no way the CA API could know whether it should do that or
>>>> > not, so
>>>> > it
>>>> > doesn't and it falls on you to do it yourself.
>>>> >
>>>> > - 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
>>>> >
>>>> >
>>>
>>> --
>>> Tim Mooney ([email protected]) (630)252-5417
>>> Software Services Group (www.aps.anl.gov)
>>> Advanced Photon Source, Argonne National Lab
>>>
>>>
>>
>>
>
>
> --
> Tim Mooney ([email protected]) (630)252-5417
> Software Services Group (www.aps.anl.gov)
> Advanced Photon Source, Argonne National Lab
>
>

-- 
Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System