More heap corruption / allocator lock problems

[Joel Sherrill]

Paul Neelands wrote:

> Regarding solution b)
> 
> If the special "gc" thread approach is used, how does one insure that it is
> run at an appropriate time? i.e. It may not free memory more quickly unless
> the "gc" thread is highest priority, which ends up being effectively the
> same as the list approach but done via a thread and it's overhead.
> Presumably the malloc/free list approach solves this problem and eliminates
> the additional interface complexity of solution a)

Personally I don't like adding a special thread because it increases
bulk and complexity.  Even adding it to the IDLE thread forces
requirements on BSP and CPU specific ones.

Till and I have emailed privately with a modified solution.

   + Heap blocks actually ALWAYS have enough memory to be a
     SuperCore Chain_Node.  This is required because free
     blocks are managed as a SuperCore Chain.
   + When free() is called at inappropriate times, it could
     do a Chain_Append to a special GC Chain
   + When malloc() is called at appropriate times, it could
     free() all blocks on the GC chain.

My one odd thought is that perhaps adding this logic to the
Region manager would be more appropriate so all regions would
have this behavior.

> Paul Neelands
> 
> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill at OARcorp.com]
> ...
> 
>>b) free could be enhanced:
>>
>>   if 'free' is called while _Thread_Dispatch_disable_level > 0,
>>   it sends its pointer argument to a special "gc" thread which
>>   will eventually execute the real 'free'. The synchronization
>>   mechanism *must* be nonblocking, of course, to avoid the
>>   same kind of problem...
>>
>>While I feel that b) is 'hackish', it could certainly provide
>>backwards compatibility...
> 
> 
> Another simpler approach to this might be to have a list like you suggest
> but check that it is non-empty on each malloc or free when
> _Thread_Dispatch_disable_level
> is == 0.  It doesn't free memory as quickly as a gc thread would but it
> would get it into
> the heap when it matters.
> 
> 
>>RFC
>>
>>-- Till
> 
> 
> 
> 
> 
> 
> 


-- 
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