What are the __retarget_lock functions?

[Thomas Kindler]

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