This is the mail archive of the
mailing list for the newlib project.
Re: [PATCH, newlib] Allow locking routine to be retargeted
On 11/11/16 11:56, Sebastian Huber wrote:
----- Thomas Preudhomme <firstname.lastname@example.org> schrieb:
On 10/11/16 20:32, Freddie Chopin wrote:
This could work, if only malloc() was not protected with the statically
created _LOCK_T lock itself, which would need such initialization
too... I don't see any other way to write such function for an RTOS
which has mutexes with size greater than "uintptr_t" (probably huge
majority). You could do it with a static pool of storage for mutexes,
but then you'd have to know upfront how many you want and your RTOS
would have to allow creation of locks in provided storage (most of them
allow that, but not all). Maybe I just don't see the simplest solution
to this problem?
Why do mutex needs to be more than a single integer? How big are mutex in RTOS
typically in your experience?
This depends on what features the RTOS wants to support. For example SMP, locking protocols, blocking on a wait queue, user-provided or external-provided storage, nesting, etc.
For RTEMS a recursive mutex with support for priority inheritance (or OMIP) and SMP (optional) needs 20 bytes on a 32-bit machine for example:
Right, I didn't think of extra features. The one thing I could think of would be
to remove usage of the static initializers and only use the function initializer
which could do a malloc if needed. The issue you described with malloc can be
avoided by redefining malloc_lock so as not to call the generic lock function.
Now whether this is worth the trouble is another issue because that would
require more work. Thanks a lot for the feedback, I'm glad you pointed out the
pitfalls in that approach. It is time to go back to the drawing board.