Re: [Xenomai] posix skin pthread_create issue

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

On 09/17/2012 10:46 PM, Pierre Quelin wrote:

> 
> Le 17/09/2012 21:50, Gilles Chanteperdrix a écrit :
>> On 09/17/2012 09:32 PM, Pierre Quelin wrote:
>>
>>>>>>> After your answer, I try xenomai 2.6.1 and I increase the size of the
>>>>>>>     private stack pool from 128 to 2048 with the same result.
>>>>>>>
>>>>>>> Is there any limits for the number of threads in Xenomai ?
>>>>>> Not that I know of. There are only a few dynamic allocations in the
>>>>>> various pools you already mentioned. The corresponding options are:
>>>>>> XENO_OPT_REGISTRY_NRSLOTS (maximum number of objects in the registry,
>>>>>> each thread is registered in the registry)
>>>>>> XENO_OPT_SYS_HEAPSZ (system heap, used for various calls to xnmalloc)
>>>>>> XENO_OPT_SEM_HEAPSZ (semaphore heap, use for allocating 4 bytes per
>>>>>> thread + 4 bytes per mutex)
>>>>>>
>>>>>> But anyway, debugging the issue you have should be relatively easy by
>>>>>> adding printfs/printks, starting from src/skins/posix/thread.c (function
>>>>>> __wrap_pthread_create), continuing in ksrc/skins/posix/syscall.c,
>>>>>> function __pthread_create, etc...
>>>>> I try to obtain information about my context but all seems to be ok.
>>>> You have to put a "pause" after the failing call to pthread_create,
>>>> because otherwise if calling exit, when the process fails, all the
>>>> memory it allocated in the various pools is freed.
>>> I found the problem. It seems that the private sem heap is to small.
>>>
>>> I'm not sure about which parameter to increase in kernel menu so at
>>> first I increase :
>>
>> "private sem heap" -> "private semaphores heap", how can this not be clear?
> This link is clear, but I don't understand the link between "private 
> semaphores heap", "global semaphores heap" and "system heap" ?
> I just try to fix the right values for my context and my application.


There is no link between the various heaps, which is the reason why they
have separate configuration options. Now if the question is to know how
much space in each heap consumes a thread, a mutex, etc... I guess
nobody ever did the computation. For the semaphore heaps at least it is
clear: each thread consumes 4 bytes in the semaphore heap, each mutex
consumes 4 bytes in the private or global heap depending on whether it
is a process-private, or global mutex (for posix mutexes, this is
related to pthread_mutexattr_setpshared).

>>> ? Is calling pthread_set_mode_np (PTHREAD_WARNSW, 0) inhibits the rise
>>> of the signal for a page fault?
>>
>> Yes, it inhibits the rise of the signal for any cause of switch to
>> secondary mode. Quoting the documentation:
>>
>> "PTHREAD_WARNSW, when set, cause the signal SIGXCPU to be sent to the
>> current thread, whenever it involontary switches to secondary mode;"
>>
>> so, obviously, when clear, the SIGXCPU is NOT SENT to the current thread
>> whenever it involontary switches to secondary mode. What else did you
>> understand when reading this documentation ?
> 
> I don't understand that a page fault is 'just' a switch to secondary mode.


A switch to secondary mode is devastating for a real-time thread running
in primary mode.
A page fault causes a switch to secondary mode so that the Linux kernel
can handle the page fault, the only alternative is probably crashing, or
suspending the thread that had the fault. SIGXCPU is sent, if you
enabled the PTHREAD_WARNSW bit.

So, PTHREAD_WARNSW should be armed for threads which should stay in
primary mode. The critical ones.

Anyway, it is not really normal to have page faults, using mlockall and
the disabling of on-demand mappings by the I-pipe patch should prevent
page faults from happening. So, it would be interesting to know what
cause these faults.

> Before posting a message on this mailing list I tried to read all 
> documents on Xenomaiand solve the problem by myself.
> Maybe I did not read the right papers or I did not understand what I 
> have read and I apologize.


No need to apologize, the mailing list is here so that people can ask
questions. I guess there are more answers (maybe not the good ones) in
the mailing list archives than in the documentation.

Regards.

-- 
                                                                Gilles.