This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]