[PATCH, newlib] Allow locking routine to be retargeted

Thomas Preudhomme thomas.preudhomme@foss.arm.com
Fri Nov 25 12:04:00 GMT 2016



On 25/11/16 10:21, Thomas Preudhomme wrote:
>
>
> On 24/11/16 07:44, Sebastian Huber wrote:
>> Hello Thomas,
>>
>> On 23/11/16 15:38, Thomas Preudhomme wrote:
>>> 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
>>
>> 3)
>>
>> struct _lock;
>>
>> typedef struct _lock *_LOCK_T;
>>
>> #define __LOCK_INIT(class, lock) extern struct _lock _lock_ ## lock; class
>> _LOCK_T lock = &_lock_ ## lock;
>>
>> The OS must then provide struct _lock and storage for all statically initialized
>> locks.
>
> Oh nice, clever. I've check whether there is name collision in the source where
> this would lead them to use the same lock and found:
>
> newlib/libc/sys/linux/iconv/gconv_db.c: __LOCK_INIT(static, lock);
> newlib/libc/sys/linux/iconv/gconv_trans.c: __LOCK_INIT(static, lock);
>
> The one thing I worry is the risk of new lock being added with the same name.
> Fortunately this could be detected at link time by looking for relocation to
> "_lock_.*" in newlib library and check that there is no duplicate.

One issue though, this means the OS needs to be updated each time a statically 
initialized lock is added to newlib. That seems to be a bit too much coupling. 
Or am I misunderstanding how this should be used?

Best regards,

Thomas



More information about the Newlib mailing list