What are the __retarget_lock functions?

[Freddie Chopin]

On Sun, 2018-09-09 at 10:59 +0200, Thomas Kindler wrote:
> There are some things I'm not yet happy with:
> 
> 1. Each lock takes about 80 bytes

This is easily solvable (; Just stop using FreeRTOS (;

OK, but seriously. This is a consequence of FreeRTOS design, where
"everything is a queue". Your mutex is in fact a queue with length
zero, so it has dozens of useless member variables, which finally add
up to ~80 bytes. In my opinion (which is of course biased and
subjective), this design decision is extremely stupid.

In other RTOSes (including distortos - the one I'm writing), the mutex
is usually ~20-24 bytes long, so it's ~3-4x smaller, while having a lot
more features (like selectable protocol or selectable type).

> 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.

I suppose that it would be better for the "retargetable locks", but
worse for the normal case, where there is a dedicated port... This may
be a good idea though.

> 5. Each task creates 3 additional locks with __retarget_lock_init for
> stdin/out/err

The solution to this particular problem:

https://github.com/FreddieChopin/bleeding-edge-toolchain/commit/f0b85774eb0fc0ae361897511d96a214a10cceea

> 6. __retarget_lock_init() looks too complicated with the double 
> pvPortMalloc/xSemaphoreCreate

That's because the allocation step is useless. FreeRTOS handle is just
`void*`, you don't need to allocate that, just use `_LOCK_T*` directly.
FreeRTOS objects (with the standard API) are all dynamic anyway
(another very stupid decision).

> 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.

How else do you want to use a shared resource from multiple threads?

> Do I need them, if I only use them from the thread they belong to?

No, unless you open/close them with external locking. These operation
access global shared state (list of free FILE structures and
"initialized" flag of whole stdio). I'm pretty sure there may be more
accesses to global shared state, so I suppose that you cannot omit the
locks, unless you use EVERYTHING from one thread only.

Please also note that locking/unlocking is generally considered a very
quick operation (unless locking needs to block [; ). If they are slow
in FreeRTOS then... sorry [; The fact that something is very popular
doesn't really mean that it's better than alternatives (;

Regards,
FCh