rt_task_unblock() POSIX alternative

Jan Kiszka jan.kiszka at siemens.com
Tue Apr 14 12:43:53 CEST 2020


On 14.04.20 12:41, Richard Weinberger wrote:
> On Tue, Apr 14, 2020 at 12:29 PM Jan Kiszka <jan.kiszka at siemens.com> wrote:
>>> This interrupts the Linux syscall, yes. Does this also work when the
>>> thread blocks on the Xenomai/Cobalt side?
>>>
>>
>> That ::read is a Xenomai syscall, being handled in the end by
>> timerfd_read in the core. So, yes.
> 
> True that, once again I got tricked by wrapping. :-)
> 
>> There were two "tricks" needed: avoid syscall restart (as you already
>> noticed) and using __STD (i.e. __real) pthread_kill in order to get a
>> normal signal out. Oh, and the flag var should better be volatile, but
>> that may still work when lucky.
> 
> 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.

Jan

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



More information about the Xenomai mailing list