EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: CA and threads
From: Dirk Zimoch <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: [email protected]
Date: Tue, 29 Mar 2011 16:45:08 +0200
Hello Andrew,

Thank, you for your explanation.

Unfortunately this behavior bites me now. After upgrading to a new OS and thus Tcl/Tk version, it turned out that monitors in our EPICS-Tcl interface did not work any more. This is because Tcl now can be compiled "thread aware" (which has been done by the distributor) and refuses to accept commands that come from a different thread. Somehow I now have to get the Tcl callbacks back into the context of the main thread which runs an event loop that polls the ca library.

It would be nice to have the old 3.13 style behavior back where everything that interacts with the user process is the same (main) thread, even if CA uses multiple threads internally.

Dirk

Andrew Johnson wrote:
On Monday 28 March 2011 09:57:27 Dirk Zimoch wrote:
If I create a CA client context with
   ca_context_create (ca_disable_preemptive_callback);
or, what is the same, with
   ca_task_initialize();
in which thread context will then the callback handlers be called? Is it
in the context of the thread that calls ca_pend_io() or still in the
context of a separate thread? How was it implemented in 3.13?

In 3.14 the CA client callbacks are *always* made in the context of an internal CA thread, and never of the thread that called ca_pend_io() / ca_pend_event(). If you use the above calls to initialize the library the callbacks are only ever called while the other thread is still executing the ca_pend_*() library routine, so you do not have to include mutexes in your code.

It occurs to me that there *could* be some circumstances where that's not strictly true, if the ca_pend_* thread responds to a signal, but that would be fairly unusual and would probably break the rules for signal handlers anyway.

In 3.13 the callbacks were made from the thread that called ca_pend_*(), CA was not multi-threaded internally and did all its I/O using the select() OS call. The CAS still uses this approach.

- Andrew


Replies:
Re: CA and threads Robert Soliday
Re: CA and threads Andrew Johnson
References:
CA and threads Dirk Zimoch
Re: CA and threads Andrew Johnson

Navigate by Date:
Prev: How to use the "Button" object of EDM 彭少丽
Next: Re: CA and threads Robert Soliday
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: CA and threads Andrew Johnson
Next: Re: CA and threads Robert Soliday
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·