Experimental Physics and
Industrial Control System

Mark Rivers via Core-talk <[email protected]> · Sun, 12 Jan 2020 02:02:33 +0000

Hi Andrew,

> If that is the case, try moving your exitWait() call into the run() method and they should go away (and you'll have more free memory and fewer tasks running).

Thanks for the explanation and the suggestion.

Moving the exitWait() call to the run() method eliminated the warnings, as you predicted.

Mark

________________________________
From: Core-talk <[email protected]> on behalf of Johnson, Andrew N. via Core-talk <[email protected]>
Sent: Friday, January 10, 2020 5:50 PM
To: [email protected]
Subject: Re: epicsThread warnings

On 1/10/20 4:49 PM, Konrad, Martin via Core-talk wrote:

It seems like the message is emitted by
epicsThreadAwaitingJoin() [1] which seems to be a VxWorks-specific
function that gets called at the end of epicsThreadEntry() [2] (in other
words after callbackThread::run() has completed) and only if
EPICS_THREAD_CAN_JOIN is defined. It seems like the message is only
emitted if epicsThreadAwaitingJoin() hasn't been able to acquire joinSem
within a reasonable time. I'm wondering if some other code forgot to
release the semaphore.

In the VxWorks implementation that message is printed once by any joinable epicsThread that has finished its work and returns from its entry routine if no other thread calls epicsThreadJoin() on the thread within 60 seconds of it having returned. I assumed that code would only set the join flag if its parent actually uses epicsThreadJoin() to clean up, and that would normally happen under controlled conditions when a parent is waiting for the thread to exit.

In the case of the C++ API the join flag is set in the epicsThread constructor, epicsThreadJoin() is called from the epicsThread::exitWait() routine (which gets run in the epicsThread destructor), and the thread entry routine is the run() method of the associated epicsThreadRunable object.

It is legal to call thread.exitWait() from the epicsThreadRunable::run() method, which will cause all the necessary clean-up to happen when run() returns and should give you back the RAM that the thread was holding onto. If you don't do that the thread will continue to hold onto that RAM unnecessarily, and you'll see it still alive in the epicsThreadShowAll output.

I assume that instances of this particular thread are started to perform some initialization tasks when a asynPortDriver is created, and it is reasonable to assume that it had finished its work about a minute before those messages appeared. If that is the case, try moving your exitWait() call into the run() method and they should go away (and you'll have more free memory and fewer tasks running).

Should I delete that message in the next release of Base? It appears to have been useful here...

- Andrew

--
Complexity comes for free, Simplicity you have to work for.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System