This is the mail archive of the
mailing list for the newlib project.
AW: [PATCH, newlib] Allow locking routine to be retargeted
to unconditionally provide weak dummy implementation I dont think its a good idea since it has some implications:
If the newlib is compiled for single thread, no locks are required at all, so the dummy implementation/macro is doing the job to
satisfy the linker.
But for multithread its dangerous to provide a dummy since you would not see first hand there are no locks but dummys.
So my suggestion would be:
- For single thread leave the implementation as is.
- For multithread, dont provide any lock function, so linking newlib without to provide locking functions from os/kernel
would result in a linkage error, therefore forces the user not to forget to provide them.
So I think, just put something like #ifndef MULTI_THREAD around the existing macros would do it.
Betreff: Re: [PATCH, newlib] Allow locking routine to be retargeted
Von: "Freddie Chopin" <email@example.com>
An: "firstname.lastname@example.org" <email@example.com>
On Thu, 2016-11-10 at 21:32 +0100, Freddie Chopin wrote:
> void __lock_acquire(_LOCK_T lock)
> if (lock == 0)
> // lock not yet really initialized...
> if (lock == 0) // re-check due to possible race
> lock = malloc(sizeof(RealMutexFromYourRtos));
> assert(lock != 0);
I've obviously missed some curly braces for the inner "if", but I guess
you get my idea anyway (;