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: Eric Norum <eric@norum.ca>
To: "Szalata, Zenon M." <zms@slac.stanford.edu>
Cc: EPICS Tech Talk <tech-talk@aps.anl.gov>
Date: Sun, 1 May 2011 20:19:59 -0700
I think that you would be better off converting everything over to use the EPICS API -- epicsThreadCreate(...)and such.
This will be a better fit to EPICS and makes your driver useful to RTEMS folks, too.


On May 1, 2011, at 7:38 PM, Szalata, Zenon M. wrote:

> 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
>>> 
> 
> 

-- 
Eric Norum
eric@norum.ca






References:
EPICS task watch dog Szalata, Zenon M.
Re: EPICS task watch dog Till Straumann
RE: EPICS task watch dog Szalata, Zenon M.

Navigate by Date:
Prev: RE: EPICS task watch dog Szalata, Zenon M.
Next: Re: EPICS task watch dog Andrew Johnson
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 Szalata, Zenon M.
Next: Re: EPICS task watch dog Andrew Johnson
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 ·