libblock real-time behavior

[Till Straumann]

Joel Sherrill wrote:

>
>Chris Johns wrote:
>
>>Till Straumann wrote:
>>
>>>I was (again) thinking of using 'libblock' for adding
>>>caching to my NFS driver.
>>>
>>>However, I'm concerned about preemption-disabled
>>>sections in libblock.
>>>
>>So you should be.
>>
>>>Are these sections deterministic - what's the
>>>"longest" preemption-disabled section to be expected?
>>>
>>>Code like
>>>
>>>DISABLE_PREEMPTION()
>>>
>>>...
>>>
>>>free(something);
>>>
>
>From memory, this is a constant time operation.  
>

Still unnecessarily stealing cycles from higher priority threads...

And then, I can't see how this approach can provide protection
on a multiprocessor system but I believe to have asked this
in the past and must admit that I still haven't looked into RTEMS MP...

-- Till.

>
>
>A task can block when no memory is available from a region
>(which malloc/free use) but malloc() does not 
>block for memory when none is available.  When memory is
>freed and tasks are blocked, the memory will be parceled out
>to as many blocked tasks as possible.
>
>But if no tasks are waiting for memory (as is the case 
>with malloc/free), then the operation only does a bit
>of accounting to coalescesce with the previous and/or
>next block if they are free.  See cpukit/score/src/heapfree.c
>for precise details.
>
>>>...
>>>
>>>ENABLE_PREEMPTION();
>>>
>>>do not greatly enhance my confidence (I'd rather call 'free'
>>>outside of the critical section).
>>>
>>Is the use of this macro local to libblock ?
>>
>
>Yes in fact the macros are defined twice -- once in ata.c and once in
>bdbuf.c
>
>>If so is it possible to change these defines to LIBBLOCK_LOCK and LIBBLOCK_UNLOCK and
>>then reference a mutex (see network stack glue for an example) ?
>>
>
>I would think it is possible and likely faster if there are no 
>contention for the mutex.  
> 
>
>>(I ask this with-out actually checking any code)
>>
>
>:)  Application of design patterns seldom requires that unless you are
>implementing
>or debugging it. :)
> 
>
>>--
>>  Chris Johns, cjohns at cybertec.com.au
>>
>