[ECOS] Scheduler lock in Doug Lea's malloc implementation - be real careful

[Roy E Richardson]

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