This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Scheduler lock in Doug Lea's malloc implementation - be real careful
- From: Tim michals <tcmichals at yahoo dot com>
- To: bob dot koninckx at o-3s dot com
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Sat, 9 Sep 2006 06:26:33 -0700 (PDT)
- Subject: Re: [ECOS] Scheduler lock in Doug Lea's malloc implementation - be real careful
IMHO, you should use memory pools
http://ecos.sourceware.org/docs-latest/ref/memalloc.html,
also my understanding is that most OS do the same
allocation scheme. Thus if realtime is required, each
task must control its own memory allocation pool.
--- Roy E Richardson <eng_at_play@cox.net> wrote:
>
> ----- Original Message -----
> From: "Bart Veer" <bartv@ecoscentric.com>
> To: <bob.koninckx@o-3s.com>
> Cc: <ecos-discuss@sources.redhat.com>
> Sent: Thursday, September 07, 2006 12:40 PM
> Subject: Re: [ECOS] Scheduler lock in Doug Lea's
> malloc implementation
>
>
> >>>>>> "Bob" == bob koninckx <bob.koninckx@o-3s.com>
> writes:
> >
> > Bob> Can someone explain me why the default
> memory allocator locks
> > Bob> the scheduler ? I would expect it to be
> legitimate for a low
> > Bob> priority thread with no real time
> constraints to do dynamic
> > Bob> memory allocation without influencing the
> real-time behaviour
> > Bob> of threads with real-time constraints, as
> long as they have a
> > Bob> higher priority.
> >
> > I was not involved in the initial implementation
> of the memory
> > allocators, so this is not gospel. I do remember
> that the uITRON
> > compatibility layer imposed various requirements.
> >
> > I believe the theory is that the memory allocators
> should be very
> > fast. If you use an alternative locking mechanism
> like a mutex, both
> > the lock and unlock functions will themselves lock
> and unlock the
> > scheduler. When you have a memory allocator that
> takes a comparable
> > amount of time to a mutex operation, you are
> better off locking the
> > scheduler around the memory allocation rather than
> going through mutex
> > lock and unlock calls.
> >
> > If you are using a fixed block memory pool as per
> mfiximpl.hxx then
> > that theory may well be correct. If you are using
> some other allocator
> > such as dlmalloc then I suspect the theory is
> wrong and for such
> > allocators the code should use a mutex instead,
> but I have not done
> > any measurements. There are going to be
> complications, e.g.
> > average vs. maximum times.
> >
> > Bart
> >
> > --
> > Bart Veer eCos Configuration
> Architect
> > http://www.ecoscentric.com/ The eCos and
> RedBoot experts
> >
> > --
>
> The data that describes what portion(s) of the pool
> is common to all threads
> accessing the pool.
> Each successful allocate/deallocate request results
> at least 1 instance of a
> read of a portion of that common data,
> a varying quantifty of instructions to evaluate, and
> finally updates to the
> affected data value(s).
>
> The above "read/process/write" sequence is commonly
> referred to as a
> "critical instruction sequence" that requires
> a guaratee that absolutely precludes any potential
> of a 2nd operation from
> occurring while a prior one is in progress.
> To not do so allows for sporatic, unpredictable
> timing errors that are
> extremely difficult to recognize, let alone identify
> and correct.
>
> For Mr. Lee's malloc, the use of "scheduler
> lock/unlock" sequences is a
> minimal protection, valid ONLY IF one can be certain
> that no interrupt
> routine uses either allocate or dellocate. As I
> recall, there is a
> reference to this in the source comments, but I
> don't recall that free() /
> malloc() requests during an ISR will generate an
> exception if attempted.
>
> > Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> > and search the list archive:
> http://ecos.sourceware.org/ml/ecos-discuss
> >
> >
>
>
>
> --
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list archive:
> http://ecos.sourceware.org/ml/ecos-discuss
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss