[ECOS] Scheduler lock in Doug Lea's malloc implementation
Bart Veer
bartv@ecoscentric.com
Thu Sep 7 19:40:00 GMT 2006
>>>>> "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
More information about the Ecos-discuss
mailing list