Re: [Xenomai-help] xenomai user app working very slowly - "select" issue

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Landau, Bracha wrote:
> I rebuilt with 2.5.0 and that particular problem is gone.
> However, I see a different behavior between the regular implementation and the xenomai implementation:
> 
> I have a series of identical threads waiting, using select, on one of two message queues. One message queues is waited upon only by that thread, and the other is waited upon by all the threads. When the select returns the thread reads from the queue that has input ready.
> 
> I sent messages to the general queue (i.e., the one waited upon by multiple threads).
> 
> In the regular (non-xenomai) implementation, I see that the messages were processed more-or-less equally among all the waiting threads.
> 
> In the xenomai implementation, all the messages were processed by a single thread.
> 
> Is there any way to make the scheduling done more "fairly" in xenomai?

The SCHED_FIFO policy is the contrary of fairness. Have you try to use
the SCHED_FIFO policy with Linux too?

There is not much point using several thread to select on the same file
descriptor. The point of select is rather the reverse: being able to
wait for several file descriptors with only one thread. If you have

If the thread have different priorities, the woken up thread is always
the thread with the highest priority.

Other than that, I do not really understand what you are talking about,
your description of the problem is rather vague. Please post a test case.

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