Re: [PATCH, newlib] Allow locking routine to be retargeted

[Sebastian Huber <sebastian.huber@embedded-brains.de>]

On 25/11/16 13:04, Thomas Preudhomme wrote:
>
>
> 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?

Yes, but how many locks per minute are added to Newlib?

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.