[PATCH] libblock: Do resource allocation in one place

Sebastian Huber sebastian.huber at embedded-brains.de
Thu Feb 21 09:19:30 UTC 2013


On 02/21/2013 10:09 AM, Chris Johns wrote:
> Sebastian Huber wrote:
>> On 02/21/2013 03:56 AM, Chris Johns wrote:
>>> Sebastian Huber wrote:
>>>>
>>>> - /*
>>>> - * Create the worker threads.
>>>> - */
>>>> - rtems_bdbuf_swapout_workers_open ();
>>>> -
>>>
>>> Why the need to move this to the bdbuf init ? The worker threads are
>>> part of
>>> the implementation of the swapout task. This abstraction is being
>>> removed.
>>
>> The usage of worker threads is part of the configuration.
>
> Hmmm interesting point of view. Not one I see as a strong argument.
>
>> If we allocate
>> all resources in rtems_bdbuf_init() we have consistent behaviour.
>
> What determines "consistent behavior" ? Creating the tasks or letting them run
> to a blocking point ? This adds an interesting constraint to using the cache.

We have consistent behaviour if after rtems_bdbuf_init() no fatal errors can 
happen due to configuration errors or resources limits.  This makes it easier 
to detect configuration errors for users.  If rtems_bdbuf_init() fails, then we 
have a configuration problem and this is immediately obvious.  If we have some 
time later during the system startup a fatal error in a worker task, then it is 
more difficult to deduce the error reason.

>
>> The
>> initialization may be either successful or a failure and nothing else.
>> If we postpone the swapout and worker thread initialization the success
>> is unpredictable and may lead to fatal system errors depending on the
>> state of the overall application.
>
> The swapout task is deterministic as it happens in the init.

No, the swapout task allocated memory on its own.  I moved all memory 
allocations to rtems_bdbuf_init() with this patch.

> The worker
> threads, yes they could fail once the scheduler lets swap out run, but I fail
> to see the state argument. Either you have the resources to build a working
> system or you do not. The sequence not should not effect this. If the worker
> threads fail to start later and did before, whatever used the worker thread
> resources should fail later or you have another type of design issue.

Later is always bad if can know it earlier.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the devel mailing list