This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: What are the __retarget_lock functions?
On 25.08.2018 00:25, Freddie Chopin wrote:
On Fri, 2018-08-24 at 22:42 +0200, Thomas Kindler wrote:
Do I need to implement them (how?)
Do you need to implement them - no, but using any of the functions
which needs them will be allowed only from single thread (maybe with
exception of malloc/free if you provide __malloc_lock/unlock()).
I think that implementations from my RTOS will answer your "how"
question:
https://github.com/DISTORTEC/distortos/blob/master/source/newlib/locking.cpp
Ok, so here's a draft implementation for FreeRTOS:
https://gist.github.com/thomask77/3a2d54a482c294beec5d87730e163bdd
To speed up malloc, I'm using a critical section instead of a mutex - seems ok,
because malloc() doesn't use FreeRTOS API functions inside the lock.
That's not possible for the other locks though.
There are some things I'm not yet happy with:
1. Each lock takes about 80 bytes
2. That's 720 bytes + malloc overhead just for the 9 static locks
3. The way newlib/libc/misc/lock.c is implemented, it's either all-or-nothing:
The linker can garbage collect arc4random(), but not the arc4random_mutex.
4. It would be better, if arc4random just created it's own lock on first use.
5. Each task creates 3 additional locks with __retarget_lock_init for stdin/out/err
6. __retarget_lock_init() looks too complicated with the double
pvPortMalloc/xSemaphoreCreate
Why are they needed and what do they do?
They are not needed (; They implement all the locking for newlib. The
most frequent use-case is stdio - each file has its own lock and
there's also a global lock for accessing the list of free FILE
structures (when using fopen() and similar). Without these locks using
anything from stdio is basically allowed from one thread only.
I don't understand why the 3 file locks per thread are needed. There seems to be
an awful lot of locking going on - every printf("\n") now takes a lock.
Do I need them, if I only use them from the thread they belong to?
Could I do additional checks for this in the retarget functions?
Best regards,
Thomas