A software engineer that would call malloc() from an ISR is either a
freshman student or a Luddite.
--- In l..., "Paul Curtis" wrote: >
> Markus,
>
> > Is the malloc() (and free() for that matter) implementation as it's used > > in Crossworks irq save? I mean if I call malloc (or
free) from within an > > isr routine (which eventually interrupts another
ongoing malloc() ) will > > things go wrong? I haven't found that
information in the docs (which
> > does not necesairly mean its not there but just that I haven't found it). >
> I can categorically state that malloc and free are not re-entrant and should > not be called form an ISR. In a CTL environment they
are protected by a
> semaphore but still can't be called from an ISR.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
Reply by Paul Curtis●August 25, 20082008-08-25
Markus,
> Is the malloc() (and free() for that matter)
implementation as it's used
> in Crossworks irq save? I mean if I call malloc (or free) from within an
> isr routine (which eventually interrupts another ongoing malloc() ) will
> things go wrong? I haven't found that information in the docs (which
> does not necesairly mean its not there but just that I haven't found
it).
I can categorically state that malloc and free are not re-entrant and should
not be called form an ISR. In a CTL environment they are protected by a
semaphore but still can't be called from an ISR.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by mjames_doveridge●August 25, 20082008-08-25
--- In l..., Markus Zingg wrote: >
> Hi Group,
>
> Is the malloc() (and free() for that matter) implementation as it's used > in Crossworks irq save? I mean if I call malloc (or
free) from within an > isr routine (which eventually interrupts another
ongoing malloc() ) will > things go wrong? I haven't found that
information in the docs (which
> does not necesairly mean its not there but just that I haven't found it). >
Just don't do it. Like Richard implies, it's almost beyond belief
that
malloc/free are interrupt-safe. They are thread-safe, but only
because threads can wait and the calls can be protected with a
mutex/semaphore. Interrupts cannot wait. If you need some buffers,
protocol-parsers or the like structures/objects/whatever in
interrupt/s, you will need to pre-allocate them and supply them to the
interrupt in a safe manner. This can be very awkward to do if
interrupts are nested - I do not allow nested interrupts in my app for
that very reason.
Rgds,
Martin
Reply by "FreeRTOS.org Info"●August 25, 20082008-08-25
> Hi Group,
>
> Is the malloc() (and free() for that matter) implementation
> as it's used in Crossworks irq save? I mean if I call malloc
> (or free) from within an isr routine (which eventually
> interrupts another ongoing malloc() ) will things go wrong? I
> haven't found that information in the docs (which does not
> necesairly mean its not there but just that I haven't found it).
I cannot say for definite ref the CrossWorks libraries, but it would not be
normal for malloc and free to be thread/interrupt safe - and definitely not
normal to call one of these functions from an interrupt as generally they
can be lengthy and non-deterministic operations.
Regards,
Richard.
+ http://www.FreeRTOS.org
17 official architecture ports, more than 6000 downloads per month.
+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.
Reply by Markus Zingg●August 25, 20082008-08-25
Hi Group,
Is the malloc() (and free() for that matter) implementation as it's used
in Crossworks irq save? I mean if I call malloc (or free) from within an
isr routine (which eventually interrupts another ongoing malloc() ) will
things go wrong? I haven't found that information in the docs (which
does not necesairly mean its not there but just that I haven't found
it).
