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.


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

More information about the Xenomai mailing list