>>>>> "Bob" == bob koninckx <[EMAIL PROTECTED]> 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
