On 2011-06-23 13:29, Gilles Chanteperdrix wrote:
> On 06/23/2011 11:09 AM, Jan Kiszka wrote:
>> On 2011-06-23 11:05, Gilles Chanteperdrix wrote:
>>> On 06/23/2011 09:38 AM, Jan Kiszka wrote:
>>>>> +#ifdef CONFIG_XENO_FASTSYNCH
>>>>> + if (xeno_get_current() != XN_NO_HANDLE &&
>>>>> + !(xeno_get_current_mode() & XNRELAX) && buf_pool_get()) {
>>>>> + struct print_buffer *old;
>>>>> +
>>>>> + old = buf_pool_get();
>>>>> + while (old != buffer) {
>>>>> + buffer = old;
>>>>> + old = buf_pool_cmpxchg(buffer, buffer->pool_next);
>>>>
>>>> Though unlikely, it's still possible: The buffer obtained in the last
>>>> round may have been dequeued meanwhile and then freed (in case a third
>>>> buffer was released to the pool, filling it up to pool_capacity).
>>>
>>> I do not get it: it seems to me that if the current head (that is
>>> buf_pool_get()) is freed, then the cmpxchg will fail, so we will loop
>>> and try again.
>>
>> Problematic is the dereferencing of the stale buffer pointer obtained
>> during the last cmpxchg or via buf_pool_get. This happens before the new
>> cmpxchg.
>
> Ok. Got it, that would be a problem only if the stale pointer pointed to
> an unmapped area, but ok, better avoid freeing the buffers. I guess it
> would not be a problem as applications tend to have a fixed number of
> threads anyway.That is a risky assumption, proven wrong e.g. by one of our applications. Threads may always be created or destroyed depending on the mode of an application, specifically if it is a larger one. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list [email protected] https://mail.gna.org/listinfo/xenomai-core
