rt_task_unblock() POSIX alternative

Jan Kiszka jan.kiszka at siemens.com
Tue Apr 14 13:30:03 CEST 2020


On 14.04.20 13:05, Richard Weinberger wrote:
> On Tue, Apr 14, 2020 at 1:02 PM Jan Kiszka <jan.kiszka at siemens.com> wrote:
>>
>> On 14.04.20 12:56, Richard Weinberger wrote:
>>> On Tue, Apr 14, 2020 at 12:44 PM Jan Kiszka <jan.kiszka at siemens.com> wrote:
>>>
>>>>> While we are here, is there a guarantee that rt_task_unblock() can unblock
>>>>> a thread in every situation?
>>>>> I have a large Xenomai 2 application on my desk which seems to assumes that.
>>>>
>>>> IIRC, it does so for the native/alchemy API.
>>>>
>>>>>
>>>>> As far as I understand it, unblocking tasks is best effort.
>>>>> /me has pthread_mutex_lock() in mind which must not return -EINTR as
>>>>> required by POSIX.
>>>>>
>>>>
>>>> Well, when mixing APIs, you can end up in such conflicting goals, indeed.
>>>
>>> I fear more about Xenomai internals which are now based on POSIX APIs.
>>> IIRC we talked regarding this issue some time ago.
>>>
>>> Found the mail:
>>> https://www.xenomai.org/pipermail/xenomai/2019-July/041221.html
>>
>> Indeed, there is a todo...
> 
> No big deal. I actually try hard to get rid of all rt_task_unblock()
> users in our code base. :-)
> 

Well, some fix is needed in any case, at least to the docs stating the 
rt_mutex_acquire* will return -EINTR when interrupted by 
rt_task_unblock. That is currently not true.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



More information about the Xenomai mailing list