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  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 
<== Date ==> <== Thread ==>

Subject: RE: EPICS task watch dog
From: "Szalata, Zenon M." <zms@slac.stanford.edu>
To: "Straumann, Till" <strauman@slac.stanford.edu>
Cc: EPICS Tech Talk <tech-talk@aps.anl.gov>
Date: Sun, 1 May 2011 19:38:53 -0700
Till, Thank you for your input.
I understand your suggestion.
There is another related issue, which I am not sure about.
In the existing driver code, the task is created with a call to vxWorks routine taskSpawn(...).  Here is a code fragment:

int status;
...
status=taskSpawn(...);
...
taskwdInsert( status,NULL,NULL);
...

This does not compile since taskwdInsert expects the first argument of type epicsThreadId.

I am making a wild guess, that perhaps, before calling taskwdInsert routine, I need to call epicsThreadGetID, which should return epicsThreadId type identifier, which then I could pass to taskwdInsert.

Seems that it should work, but having little experience with tasks, I would like an assurance that this the right way.

Thanks Till,
Zen

> -----Original Message-----
> From: Till Straumann [mailto:strauman@slac.stanford.edu]
> Sent: Saturday, April 30, 2011 11:26 PM
> To: Szalata, Zenon M.
> Cc: Williams Jr., Ernest L.; EPICS Tech Talk
> Subject: Re: EPICS task watch dog
> 
> It seems that the epicsThreadId in the vxWorks implementation of
> OSI is just the vxworks TID. Hence, passing a vxworks TID that
> you obtain using straight vxworks calls on to EPICS and casting
> to (epicsThreadId) should work but is of course extremely
> ugly since you rely on non-public implementation details
> (and you have no guarantee that these will not change in
> future EPICS releases).
> 
> Your example would be much better using EPICS APIs only:
> 
> epicsThreadId tid;
> 
> /* EPICS_THREAD_NAME is 'const char *' */
> 
> if ( (tid = epicsThreadGetId( EPICS_THREAD_NAME )) ) {
> 
>    taskwdRemove( tid );
> 
>    /*** see comment ***/
> }
> 
> Note that the EPICS API doesn't offer an equivalent for
> 'taskDelete()' and this probably for good reasons: Just
> asynchronously deleting a task is almost always a very bad
> idea since you have no control over what the task is doing
> when you pull the rug under its feet.
> 
> You need to implement a synchronization mechanism to let
> the task know that it should terminate and then wait
> for termination instead of using 'taskDelete()'.
> 
> HTH
> -- Till
> 
> 
> On 04/30/2011 11:08 PM, Szalata, Zenon M. wrote:
> > I am working to upgrade an old device driver module so it can be used
> > with EPICS R3.14.11 and vxWorks 6.6. It is currently used with EPICS
> > R3.13.2 and some older version of vxWorks. The author is using the task
> > watchdog routines in a way that I find confusing and am not able to make
> > a decision on how to proceed.
> >
> > The task watchdog routines in EPICS R3.13.2 take int argument. An
> > example is void taskwdRemove(int tid).
> >
> > In EPICS R3.14.11 this routine is now epicsShareFunc void
> > taskwdRemove(epicsThreadId tid).
> >
> > The argument is now is a pointer to a structure. In itself, that is not
> > surprising. The confusing part is that the author is using vxWorks
> > routines, which use an int type handle and the EPICS routines which are
> > called with the vxWorks handles. Here is a code fragment:
> >
> > int tid;
> >
> > if ( (tid = taskNameToId( NAME )) != ERROR )
> >
> > {
> >
> > taskwdRemove( tid );
> >
> > taskDelete( tid );
> >
> > }
> >
> > Compiler does not like this because an int type is passed where a
> > pointer to a structure is expected.
> >
> > Type casting the argument to the correct type would please the compiler,
> > but I fail to see how this could possibly work correctly.
> >
> > Part of my problem is that I started to work with EPICS with R3.14.9, so
> > R3.13.2 seems prehistoric
> >
> > Someone might ask a legitimate question, why bother with this old code?
> > In fact I have a new device driver, which works with new applications.
> > Unfortunately, the "old" IOC, which is using the driver in question is
> > using a fairly extensive set of records and these would have to be
> > modified substantially to make the IOC work with a new device driver
> > code. So, I think that upgrading the device driver and preserving the
> > .db files is more likely to result in the upgraded IOC working as it did
> > before.
> >
> > Any ideas are most welcome,
> >
> > Zen
> >



Replies:
Re: EPICS task watch dog Eric Norum
Re: EPICS task watch dog Andrew Johnson
References:
EPICS task watch dog Szalata, Zenon M.
Re: EPICS task watch dog Till Straumann

Navigate by Date:
Prev: mca R7-0 Mark Rivers
Next: Re: EPICS task watch dog Eric Norum
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 
Navigate by Thread:
Prev: Re: EPICS task watch dog Till Straumann
Next: Re: EPICS task watch dog Eric Norum
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 
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 ·