On 06/23/2011 01:36 PM, Jan Kiszka wrote:
> 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:
>>>>>> +        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.

The situation which would be problematic is to create many threads at
once, which use printf, then continues to run with just a few threads.
In that case, we would have many unfreed buffers. But as long as the
application creates and destroy threads over the time, the pool will
simply keep the buffers until next use.

> Jan


Xenomai-core mailing list

Reply via email to