EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  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  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <2022>  2023  2024 
<== Date ==> <== Thread ==>
Subject: Re: Using DPVT for non-device support purposes
From: Andrew Johnson via Tech-talk <tech-talk at aps.anl.gov>
To: "Wang, Andrew" <wang126 at llnl.gov>, EPICS tech-talk <tech-talk at aps.anl.gov>
Date: Fri, 25 Nov 2022 13:14:15 -0600
Hi Andrew,

On 11/25/22 12:34 PM, Wang, Andrew via Tech-talk wrote:
I was wondering about the use of the dpvt pointer in a subroutine that the aSub record uses when it is processed. My understanding is that the dpvt pointer is used for device support, but I was wondering if it can also be used as an alternative to static variables
Yes, the subroutine record types don't have any device support associated with them, so your subroutines are welcome to use that pointer for themselves if they wish. Record subroutines have to be re-entrant if they are used by more than one record instance, so static variables are not as useful in them as shown by your example — you would need to protect any accesses to static variables with an epicsMutex if you did want to use them as such since two subroutines could get processed by different threads at the same time, leading to a potential race condition.

An additional related question: Suppose for device support, dpvt pointer points to a struct, which has a special free function associated with it (the struct might contain member variables that are dynamically allocated). Where can that be called so that there is no memory leaks from the IOC?

The aSub record type has a function-pointer field prec->cadr which your subroutine can point to a cleanup function. It will be called (and passed prec) and then prec->cadr set to NULL whenever the SNAM field of the record gets changed.

Note that the cadr won't be called when the IOC shuts down, for that you would need to register an epicsAtExit() routine to be called when the process exits. However if it's just freeing memory that you're worried about the IOC process exiting will normally return all of the process RAM back to the OS automatically; I would only worry about that when embedding the IOC into and running it within the context of another process.

HTH,

- Andrew
-- 
Complexity comes for free, Simplicity you have to work for.
References:
Using DPVT for non-device support purposes Wang, Andrew via Tech-talk
Navigate by Date:
Prev: Using DPVT for non-device support purposes Wang, Andrew via Tech-talk
Next: LabJack R3-0 available Mark Rivers via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <2022>  2023  2024 
Navigate by Thread:
Prev: Using DPVT for non-device support purposes Wang, Andrew via Tech-talk
Next: LabJack R3-0 available Mark Rivers via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <2022>  2023  2024 
ANJ, 25 Nov 2022 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·