[Xenomai] Posix named semaphore used by two separate applications

Jan Kiszka jan.kiszka at web.de
Sat May 26 07:09:19 CEST 2018


On 2018-05-25 11:18, Paal Tamas wrote:
> 
> 
> Jan Kiszka <jan.kiszka at siemens.com> írta:
>> On 2018-05-24 16:18, Jan Kiszka wrote:
>>> Again, re-adding the list - please always use "reply to all".
>>>
>>> On 2018-05-24 13:56, Paal Tamas wrote:
>>>>
>>>>
>>>> Jan Kiszka <jan.kiszka at siemens.com> írta:
>>>>> [re-adding the list]
>>>>>
>>>>> On 2018-05-24 13:35, Paal Tamas wrote:
>>>>>>
>>>>>>
>>>>>> Jan Kiszka <jan.kiszka at siemens.com> írta:
>>>>>>> On 2018-05-24 10:50, Paal Tamas wrote:
>>>>>>>> I would like to use the same named semaphore in two separate Xenomai binaries. I am using the Posix skin. It does not work as I am expecting it. 
>>>>>>>> The first instance of my test application creates a named semaphore. It goes to sleep after that. The second instance of the same applications starts than. It realizes that the semaphore with the name already exists, so it opens it. The sem_open() returns a valid (like) pointer. After that all semaphore functions in this second application return EINVAL (22) (Invalid argument). Both the sem_wait() and the sem_close() function behave this way.
>>>>>>>>
>>>>>>>> The same procedure worked fine in 2.6.2.1 (the previous version I used). I tried 3.0.5 and the latest git repository too. The same bad behavior there.
>>>>>>>>
>>>>>>>
>>>>>>> Did you configure userspace with --enable-pshared?
>>>>>>>
>>>>>>
>>>>>> Yes. I invoked the "configure" script this way:
>>>>>>
>>>>>> ./configure --with-core=cobalt --enable-smp --enable-pshared
>>>>>
>>>>> OK.
>>>>>
>>>>>>
>>>>>> This is my configuration:
>>>>>>
>>>>>> /xeno-config --info
>>>>>> Xenomai version: Xenomai/cobalt v3.0.6 -- #50ef005 (2018-05-13 16:21:13 +0200)
>>>>>> Linux clickandmove-NUC 4.9.51xeno #1 SMP Wed May 23 05:14:47 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
>>>>>> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-4.9.51xeno root=UUID=7e90a17b-1ea0-4b84-849f-7d621fe6d580 ro quiet splash vt.handoff=7
>>>>>> I-pipe release #5 detected
>>>>>> Cobalt core 3.0.6 detected
>>>>>> Compiler: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
>>>>>> Build args: --with-core=cobalt --enable-smp --enable-pshared
>>>>>>
>>>>>> When I tried the git repository I cheated a bit. I could not find the configure script (neither some others) and all the makefile.in files were missing, so I copied these files from the xenomai-3.0.6.tar.bz2. I've never tried the git  repositore before, always used the bz2 file(s). In case of the 3.0.5 version I used the bz2 file for the tests.
>>>>>
>>>>> Just run scripts/bootstrap when using a git checkout.
>>>>
>>>> Do I need any parameters to the scripts/bootstrap script in this case or I should simply run it?
>>>>
>>>>>
>>>>> To ensure that we are truly hunting a Xenomai issue: Does your testcase
>>>>> work with plain Linux?
>>>>>
>>>>
>>>> Yes, it works fine under plain Linux. Sorry that I forgot to mention this...
>>>
>>> Confirmed.
>>>
>>> In fact, your test also exposes some cleanup issue: When terminating a
>>> process, Xenomai does not remove the semaphore, and you need to reboot
>>> to remove the object.
>>
>> Correction: This is not a wrong behavior, Linux does the same. The test
>> code just has no chance to clean up a preexisting sem because of the
>> other problem (EINVAL).
>>
>> Jan
>>
>>>
>>> Will look into these problems.
>>>
>>> Jan
>>>
>>
> I saw that you created some patches on this issue and modified the git repository. I cloned the latest one, rebuilt Xenomai and my test application but the original EINVAL, Invalid Argument error in case of the second instance of the test application still exists. In other words I do not see any change in the behavior.
> Should I rebuild the Linux kernel too?

Yes, the fix is targeting the kernel code.

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://xenomai.org/pipermail/xenomai/attachments/20180526/64d80c89/attachment.sig>


More information about the Xenomai mailing list