[Xenomai-help] Which process synchronization primitive?

[Xenomai-help] Which process synchronization primitive?

[Daniele Nicolodi]

Hello. I'm writing a data acquisition system (the code will be released
open source soon) and i chose to use Xenomai to obtain real time
performances.

The design of the system is inspired from JACK http://jackaudio.org/.
Different functionalities are implemented in separate processes that
communicate via a shared memory segment. However I need a processes
synchronization primitive. In the first toy implementation of the system
I have been using simple pipes and blocking reads (as is done in jack)
and it work quite well. However I learned this mechanism is not suitable
for real time.

Given that I would like to use the Xenomai Posix skin, so that my
applications will build also without Xenomai support, which process
synchronization primitive you suggest? Which is the overhead of
different solutions?

I think message queues can work well but I'm not sure they are the best
choice when I do not have to communicate any message. Would be
semaphores best suited to my needs?

Thanks. Cheers,
-- 
Daniele

Re: [Xenomai-help] Which process synchronization primitive?

[Gilles Chanteperdrix]

Daniele Nicolodi wrote:
> Hello. I'm writing a data acquisition system (the code will be released
> open source soon) and i chose to use Xenomai to obtain real time
> performances.
> 
> The design of the system is inspired from JACK http://jackaudio.org/.
> Different functionalities are implemented in separate processes that
> communicate via a shared memory segment. However I need a processes
> synchronization primitive. In the first toy implementation of the system
> I have been using simple pipes and blocking reads (as is done in jack)
> and it work quite well. However I learned this mechanism is not suitable
> for real time.
> 
> Given that I would like to use the Xenomai Posix skin, so that my
> applications will build also without Xenomai support, which process
> synchronization primitive you suggest? Which is the overhead of
> different solutions?
> 
> I think message queues can work well but I'm not sure they are the best
> choice when I do not have to communicate any message. Would be
> semaphores best suited to my needs?

You can use process-shared mutexes or semaphores. But there is something
which must be said clearly: compiling or not with Xenomai support is all
or nothing. Either you build all the applications with Xenomai posix
support or none of them. There is no way you can synchronize a real-time
thread with a non real-time thread without loosing determinism. And
beware of the kind of priority inversions which would result from
calling a Linux system call while holding a mutex shared with real-time
processes, as explained here:

http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Chasing_the_unwanted_mode_switches.

-- 
					    Gilles.

Re: [Xenomai-help] Which process synchronization primitive?

[Daniele Nicolodi]

Gilles Chanteperdrix wrote:
>> I think message queues can work well but I'm not sure they are the best
>> choice when I do not have to communicate any message. Would be
>> semaphores best suited to my needs?
> 
> You can use process-shared mutexes or semaphores.

There is somewhere a comparison of the overhead of the different
solutions? Do I need to do my own benchmarks? Is the API the only
difference?

> But there is something
> which must be said clearly: compiling or not with Xenomai support is all
> or nothing. Either you build all the applications with Xenomai posix
> support or none of them. There is no way you can synchronize a real-time
> thread with a non real-time thread without loosing determinism.

I understood this reading the documentation (and it is fairly
intuitive). I would like to use the posix skin to be able to compile my
application also on an host without xenomai support (and of course give
up the real time capability).

> And
> beware of the kind of priority inversions which would result from
> calling a Linux system call while holding a mutex shared with real-time
> processes, as explained here:
> 
> http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Chasing_the_unwanted_mode_switches.

I was just reading this.

Thanks! Cheers,
-- 
Daniele

Re: [Xenomai-help] Which process synchronization primitive?

[Gilles Chanteperdrix]

Daniele Nicolodi wrote:
> Gilles Chanteperdrix wrote:
>>> I think message queues can work well but I'm not sure they are the best
>>> choice when I do not have to communicate any message. Would be
>>> semaphores best suited to my needs?
>> You can use process-shared mutexes or semaphores.
> 
> There is somewhere a comparison of the overhead of the different
> solutions? Do I need to do my own benchmarks? Is the API the only
> difference?

Mutexes have the lowest overhead, since they can be handled in
user-space starting with the 2.5 branch.

Differences betwenn mutexes and semaphores are the same with Xenomai
than with any other known API: mutexes are binary semaphores with a
notion of ownership.

> 
>> But there is something
>> which must be said clearly: compiling or not with Xenomai support is all
>> or nothing. Either you build all the applications with Xenomai posix
>> support or none of them. There is no way you can synchronize a real-time
>> thread with a non real-time thread without loosing determinism.
> 
> I understood this reading the documentation (and it is fairly
> intuitive). I would like to use the posix skin to be able to compile my
> application also on an host without xenomai support (and of course give
> up the real time capability).
> 
>> And
>> beware of the kind of priority inversions which would result from
>> calling a Linux system call while holding a mutex shared with real-time
>> processes, as explained here:
>>
>> http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Chasing_the_unwanted_mode_switches.
> 
> I was just reading this.
> 
> Thanks! Cheers,


-- 
					    Gilles.

Re: [Xenomai-help] Which process synchronization primitive?

[Gilles Chanteperdrix]

Daniele Nicolodi wrote:
> Gilles Chanteperdrix wrote:
>> Daniele Nicolodi wrote:
>>> Gilles Chanteperdrix wrote:
>>>>> I think message queues can work well but I'm not sure they are the best
>>>>> choice when I do not have to communicate any message. Would be
>>>>> semaphores best suited to my needs?
>>>> You can use process-shared mutexes or semaphores.
>>> There is somewhere a comparison of the overhead of the different
>>> solutions? Do I need to do my own benchmarks? Is the API the only
>>> difference?
>> Mutexes have the lowest overhead, since they can be handled in
>> user-space starting with the 2.5 branch.
>>
>> Differences betwenn mutexes and semaphores are the same with Xenomai
>> than with any other known API: mutexes are binary semaphores with a
>> notion of ownership.
> 
> Thanks for the clarification. I have been reviewing the documentation
> and I think that what I need is a mutex with a condition variable shared
> between processes, or a semaphore.
> 
> The reason is that in my application I have processes that consume data
> produced by other processes, and I need to suspend the execution of the
> consumer until the producer has new data to handle.
> 
> Are condition variables also implemented in user space, so that their
> overhead is smaller compared to semaphores?

No. Condition variables imply scheduler decisions and context switches,
which can only occur in kernel-space, so, it would not really make sense
to implement them in user-space. The only case for which it would be
interesting is when you are signaling a condition while no thread is
waiting for it, but this case, is not really interesting in practice.

Please do not forget to C the mailing list.

-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com