This is the mail archive of the 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

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


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

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,


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