EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: RE: ca_repeater bug (probably observable only on RTEMS)
From: "Jeff Hill" <[email protected]>
To: "'Kate Feng'" <[email protected]>
Cc: "'Till Straumann'" <[email protected]>, "'Eric Norum'" <[email protected]>, <[email protected]>
Date: Fri, 17 Sep 2004 15:17:29 -0600
> However, the IOC did not exit and cause RTEMS shut down if I add
> one clock tick of  delay

The CA client library tests to see if the repeater is running by temporarily
binding to its port. If it's not running it spawns a repeater process (on
RTEMS a thread). This leaves a small window of opportunity for multiple
repeater daemons to be spawned if two CA client contexts initialize on the
same host at nearly the same instant in time. The likelihood of experiencing
this window increases since the CA repeater daemon's thread runs at a
relatively low priority. During design I was fully aware of this
opportunity. I therefore, included code within the repeater daemon to detect
that a repeater is already running and silently shutdown as necessary. The
exit() system call was used during this shutdown, but clearly an alternative
mechanism will be needed.

As is often the case with one tick delays (hibernations) on multi-threaded
systems this introduces opportunity for a lower priority thread to run
earlier (in this case the repeater daemon) thereby closing a thread
interaction window.

Jeff

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Kate Feng
> Sent: Friday, September 17, 2004 2:05 PM
> To: Jeff Hill
> Cc: 'Till Straumann'; Eric Norum; [email protected]
> Subject: Re: ca_repeater bug (probably observable only on RTEMS)
> 
> Jeff Hill wrote:
> 
> > This code was written a long time ago. With R3.13 it executes as a
> thread
> > only on vxWorks, and on vxWorks exit() causes only the thread to exit.
> >
> > Of course, now with R3.14 the code runs also on other OS where exit()
> may
> > have a different behavior. In particular, on Linux, Solaris, HPUX,
> Windows,
> > etc exit() will cause the process to exit, but that behavior should
> not be
> > observed because osiSpawnDetachedProcess() is implemented on these
> systems,
> > and therefore the CA repeater always runs in an independent detached
> > process. It is not running as a thread in the IOC as is the case with
> > vxWorks.
> >
> > That leaves RTEMS. The osiSpawnDetachedProcess() function is not
> (probably
> > cant be) implemented on RTEMS and so you will end up with the CA
> repeater
> > running as an RTEMS thread. However, perhaps on RTEMS exit() causes
> the
> > RTEMS OS to shut down? That might be a more appropriate implementation
> of
> > exit() compared to vxWorks.
> >
> 
> However,  the IOC  did not exit and  cause RTEMS shut down if I  add
> one clock tick of  delay after motor initialzation.  It works fine for
> the
> workaround.    Assuming the answers to the above questions are yes,
> perhaps EPICS  had  enough intelligence to  undo the OS exit() if given
> one clock tick of delay to  figure out ?   Is this why the workaround
> works ?
> 
> Thanks,
> Kate
> 
> 
> >
> > What symptoms did you observe that led to finding this fix? I just
> read that
> > Kate observed a hang (which I assume means that RTEMS shut down).
> >
> > Thanks for bringing this to our attention.
> >
> > Jeff
> >
> > > -----Original Message-----
> > > From: Till Straumann [mailto:[email protected]]
> > > Sent: Wednesday, September 15, 2004 5:34 PM
> > > To: [email protected]
> > > Subject: ca_repeater bug
> > >
> > > Folks.
> > >
> > > the caRepeater thread calls 'exit()' which is not really
> > > what you want to do from the ca server (I guess)
> > >
> > > -- T.



References:
Re: ca_repeater bug (probably observable only on RTEMS) Kate Feng

Navigate by Date:
Prev: Re: ca_repeater bug (probably observable only on RTEMS) Kate Feng
Next: RE: Xycom 9660 Allison, Stephanie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: ca_repeater bug (probably observable only on RTEMS) Kate Feng
Next: Re: ca_repeater bug (probably observable only on RTEMS) Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·