[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