[PATCH, newlib] Allow locking routine to be retargeted

[Thomas Preudhomme]

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.
>