That's it. I added the session name and my test programs now can both
access the same mutex.
Thank you for the quick response. Now on to the next challenge :-)
Peter
On 2/12/2021 10:50 AM, Philippe Gerum wrote:
Peter Laurich via Xenomai <xenomai@xenomai.org> writes:
Hello,
I am in the process of migrating from Xenomai 2 to 3.1. I have
existing code with programs as individual c files where each file has
a mainline that then creates a task (rt_task_spawn()). The task spawn
part is working fine but I can not seem to access a mutex created in
one task from another task. This worked flawlessly in Xenomai 2 but I
have something not quite right now.
Here are some more details:
- I have two test programs: mutexTest1.c and mutexTest2.c
- the rt_task in mutexTest1.c successfully calls rt_mutex_create()
followed by rt_mutex_bind(). A test by calling rt_mutex_acquire()
followed by rt_mutex_release() also work so the mutex can be acquired
and released within the same program. This task then goes into a
sleep loop.
- I then start mutexTest2 which calls rt_mutex_bind() looking for the
named mutex that was created in mutexTest1; the bind has a TM_INFINITE
timeout. This call to bind never returns.
I have searched extensively for configure options and other
postings. I thought --enable-pshared would help but it did not.
Turning --enable-pshared on when configuring the build is definitely
required for sharing objects. You then need to have all peer processes
sharing a common set of objects start with the same session label passed
to the --session argument.
e.g.
$ ./configure --enable-pshared ...
$ make install
~# ./foo --session=<shared-session-name>
~# ./bar --session=<shared-session-name>
This was not required with Xenomai 2.x because all the sharing was done
in kernel space where the 'native' API implementation lived back then.
In that place, we could share everything by design. The 'native'
Xenomai 2.x API (now called Alchemy there) has been rewritten as a
user-space library in Xenomai 3.x. For this reason, objects created by
distinct processes need to live in a common storage based on TMPFS that
all peers can share using the shm_open() interface.
I
don't think that --enable-registry will do anything to make this
possible but it would allow me to see the mutex object and verify that
it was created.
The wiki states "Mutexes can be shared by multiple processes which
belong to the same Xenomai session." but I can't find a definition of
what a Xenomai session is.
I am running on an ARM target and the Xenomai test program latency works.
Any suggestions would be appreciated.
The documentation about sessions is quite terse indeed, [1] gives some
hints when describing the '--session' argument:
"Name of the session the new process will be part of (or create if not
present). If --enable-pshared was given when configuring the Xenomai
libraries, this label allows multiple processes giving the same label at
startup to share objects created by members of the same session."
[1] https://gitlab.denx.de/Xenomai/xenomai/-/wikis/App_Setup_And_Init
