Re: [ECOS] Scheduler lock in Doug Lea's malloc implementation

[Bart Veer <bartv at ecoscentric dot com>]

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

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss