EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 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: Two CA client questions
From: "Jeff Hill" <[email protected]>
To: "'Ben Franksen'" <[email protected]>
Cc: [email protected]
Date: Mon, 15 Nov 2010 14:31:11 -0700
Hi Ben,

> (1) The sequencer currently employs an "auxiliary task" which performs
> no work other than calling
> 
>   ca_pend_event(10.0)
> 
> in an endless loop. Note that the context is created with
> ca_enable_preemptive_callback.
> 
> I would be glad if I could get rid of this extra task, as I believe it
> is not necessary, but before I throw it out I'd rather make sure that
> there are no unwanted side-effects. Could such a task perhaps improve
> latency in certain situations? A comment in the code says this allows
> for connect/disconnect event processing, and it gets started with a
> slightly higher priority than the regular sequencer tasks. It is quite
> possible that the comment is out-dated, or just plain wrong.

Before R3.14 the ca client library used select to schedule everything so the
sequencer was required to call ca_pend_event periodically; this caused the
callbacks to be called and also took care of background activity such as
sending search requests and timing out unresponsive circuits. In R3.14 if
preemptive callback mode is enabled then there is no need to call
ca_pend_event periodically. In R3.14 the internal design of the library has
everything orchestrated by library private auxiliary threads.

One reason why the sequencer might have preserved the ca_poll
(ca_pend_event) polling might have been to make one code base support both
R3.14 and R3.13, but one could easily add an ifdef to enable spawning a
polling thread only if its R3.13; they will of course need to compile two
different object code versions if they will have support for both R3.13 and
R3.14 at the same site.

BTW, adding reasonable multithreading support to the R3.14 ca client library
slowed the first release some, and some have complained about this, but I
think it was the right thing to do at the time as many applications on the
client side have moved to multithreaded implementations since then.

> (2) If I create a context (with ca_enable_preemptive_callback) in one
> task, then attach to this context in another task, then delete the
> first task without destroying the context. Does the second one continue
> to work with the same context? In other words, is the task that created
> the context in any way "privileged" over tasks that merely attach to an
> existing context? I think not, but I want to be sure.

I don?t recall ever testing that usage scenario, but I believe that it will
work. Internally, the api functions find the context two ways; if a channel
identifier is passed this provides the link to the context, and otherwise
the context is located using a thread private variable. Thread private
variables are of course generally agnostic about which thread might be using
them. There also isn't any feature in the library which auto-magically
destroys a ca client context when the last thread using it goes away. So
this should work just fine - even if one isn't particularly careful about
thread creation order.

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: Ben Franksen [mailto:[email protected]]
> Sent: Sunday, November 14, 2010 2:47 PM
> To: Jeff Hill
> Cc: [email protected]
> Subject: Two CA client questions
> 
> Hi Jeff
> 
> I have two technical CA (client) questions.
> 
> (1) The sequencer currently employs an "auxiliary task" which performs
> no work other than calling
> 
>   ca_pend_event(10.0)
> 
> in an endless loop. Note that the context is created with
> ca_enable_preemptive_callback.
> 
> I would be glad if I could get rid of this extra task, as I believe it
> is not necessary, but before I throw it out I'd rather make sure that
> there are no unwanted side-effects. Could such a task perhaps improve
> latency in certain situations? A comment in the code says this allows
> for connect/disconnect event processing, and it gets started with a
> slightly higher priority than the regular sequencer tasks. It is quite
> possible that the comment is out-dated, or just plain wrong.
> 
> (2) If I create a context (with ca_enable_preemptive_callback) in one
> task, then attach to this context in another task, then delete the
> first task without destroying the context. Does the second one continue
> to work with the same context? In other words, is the task that created
> the context in any way "privileged" over tasks that merely attach to an
> existing context? I think not, but I want to be sure.
> 
> Cheers
> Ben
> --
> "Never confuse what is natural with what is habitual."
>                                    -- attributed to Mahatma Gandhi



Replies:
Re: Two CA client questions Ben Franksen
References:
Two CA client questions Ben Franksen

Navigate by Date:
Prev: Two CA client questions Ben Franksen
Next: Re: Two CA client questions Ben Franksen
Index: 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: Two CA client questions Ben Franksen
Next: Re: Two CA client questions Ben Franksen
Index: 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·