Experimental Physics and
Industrial Control System

Heinz Junkes via Core-talk <core-talk at aps.anl.gov> · Tue, 26 Jan 2021 15:47:48 -0000

I added the following to RTEMS:
in configure/os/CONFIG.Common.RTEMS
POSIX_CPPFLAGS = -D_GNU_SOURCE -D_DEFAULT_SOURCE

Just like it is already done for Linux:
in configure/os/CONFIG.COMMON.linuxCommon you can find
# Define _GNU_SOURCE and _DEFAULT_SOURCE for maximum portability
POSIX_CPPFLAGS = -D_GNU_SOURCE -D_DEFAULT_SOURCE

> Now I have some time again to return to this one...
> 
> Michael, if I understand correctly, you would like to see a run-time test that
> the attribute PTHREAD_PRIO_INHERIT can actually be used to init a mutex? Have
> you really seen that pthread_mutexattr_setprotocol(&globalAttrRecursive,
> PTHREAD_PRIO_INHERIT) succeeds but the resulting globalAttrRecursive cannot be
> used to init a mutex? If yes, I find that behavior strange and unexpected.
> 
> Heinz, do you think I should add #define D_GNU_SOURCE somewhere in the code or
> should that be done in the configuration?
> 
> Concerning "mutex not owned by task": As a mutex is used to synchronize
> different tasks, there is no specific task "owning" it permanently. The task
> that has last locked it owns it, independent of the creator task. The only
> situation where I would expect such a message is if task A has locked it but
> task B tries to unlock it. Or no task has locked it but now it is unlocked.
> That has nothing to do which who created it. The problem in the MotorRecord
> originated in the wrong check of TryLock and thus a confusion which task owned
> the mutex at run time.
-- 
https://code.launchpad.net/~dirk.zimoch/epics-base/+git/epics-base/+merge/394327
Your team EPICS Core Developers is subscribed to branch epics-base:7.0.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System