Re: [Xenomai] Multiple processes within same session

[Philippe Gerum <rpm@xenomai.org>]

On 09/06/2016 05:38 PM, Tobias Luksch wrote:
> Hello,
> 
> [Arch:x86, Processor:Corei7, Kernel: 4.1.18, Xenomai:3.0.2]
> 
> we are using several Xenomai processes communicating using shared memory (rt_heap) and a few named mutexes. The processes also create additional unnamed task, mutexes, semaphores, etc.
> After porting to Xenomai 3, I see the following problem: To access the shared heap, I start two processes within the same session (--session from command line). Shared access to the heap works, but when creating unnamed objects, e.g. a mutex, in the second process, rt_mutex_create returns -17.
> 
> Here is a small example program to reproduce this:
> 
> #include <alchemy/task.h>
> #include <alchemy/mutex.h>
> #include <stdio.h>
> 
> int main(int argc, char* argv[])
> {
> 	rt_printf("hello  world\n");
> 	RT_MUTEX mutex;
> 	int ret_val = rt_mutex_create( &mutex, NULL );
> 	rt_printf( "rt_mutex_create: %d\n", ret_val );
> 
> 	while (true)
> 	{
> 		rt_task_sleep(1000000000);
> 		rt_printf("ping\n");
> 	}
> 	return 0;
> }
> 
> Starting this program (called xeno-test here) once gives:
> $ ./xeno-test --session=test
> hello  world
> rt_mutex_create: 0
> ping
> ping
> [..]
> 
> Starting it a second time with the same session:
> $ ./xeno-test --session=test
> hello  world
> rt_mutex_create: -17
> ping
> ping
> [..]
> 
> Starting the program another time with a different session works without error. Also using differently named mutexes for both instances works.
> 
> I am not sure about the naming mechanism (if any) when creating unnamed objects like mutexes, nor about what is actually shared between processes when using the same session. It would be great if anyone could give some details on this.
> 
> Any help would be appreciated.

This is a shortcoming of the internal no-so-random name generator used
for anon objects in lib/alchemy: it should use a shared counter when
running in pshared mode for drawing unique names, but currently uses a
process-private one which is wrong. Hence the -EEXIST error received
when two processes draw the same private counter value, which is likely.

As a work around, you could provide named mutexes based on a sequence
number and the current pid value, until the name generator is fixed in
mainline.

-- 
Philippe.