This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH, newlib] Allow locking routine to be retargeted
Hi Sebastian,
I was thinking on how to solve this issue and found two possible solutions:
1) select size of lock at configure time
Instead of being an enable/disable option the configure option could take an
integer value N that determine the size of lock, default being the size of a
pointer. The lock would then be defined as an array of N integers.
Pro: LOCK_INIT works, simpler & smaller change
Cons: lock needs to be as big as the biggest lock among all the platforms you
want to target wasting a bit of space.
2) Remove static initialization of locks
Remove all LOCK_INIT and add code as required to call lock_initialize at start
up time.
Pro: you only pay the size for the lock you need (ie nothing except empty
functions in the single threaded case)
Cons: much bigger work, start up cannot support multithread
I'm more in favor of 1) because that's good enough for us and the change is
smaller in scale but I want to make sure that's good for your use case as well.
Best regards,
Thomas
On 11/11/16 11:56, Sebastian Huber wrote:
----- Thomas Preudhomme <thomas.preudhomme@foss.arm.com> 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:
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/sys/rtems/include/sys/lock.h;h=e0d77cb614b348a949e23ca4c543b1ce6a055b6d;hb=HEAD#l55
With an integer only you can implement a futex like on Linux, however, this needs a complex infrastructure in the background and provides only random fairness.