libblock real-time behavior

Joel Sherrill joel.sherrill at OARcorp.com
Thu Apr 10 13:19:51 UTC 2003



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.  

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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985



More information about the users mailing list