Re: Recursive locks? Locking API?

[Federico Terraneo <fede dot tft at hotmail dot it>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/17/2012 03:21 PM, Freddie Chopin wrote:
> Hi!
> 
> Does newlib REALLY need recursive locks? Couldn't some parts of it
> be rewritten to use normal - binary - locks only?
> 
> The other thing is the API used for locking - I've read somewhere
> that ultimately you'd like to use only sys/lock.h API for
> malloc()/free() and for env too, but actually for embedded targets
> overriding current __malloc_lock() and __malloc_unlock() is
> trivial, while using API from sys/lock.h requires configuration and
> recompilation of whole toolchain (by default all of lock functions
> are "(void)0") - maybe some default and overridable stubs (like for
> malloc/env) would be a better solution? For ARM embedded targets at
> least...
> 
> I'm talking about using newlib with tiny embedded RTOSes like 
> ChibiOS/RT, FreeRTOS etc. - these are not typical "systems", so it
> makes no sense to have a port of newlib for them, but it would be
> nice to easily use locking in your app. Some of these systems don't
> provide recursive mutexes, so recursive locking is a problem...

Some time ago I looked into this question in detail, and what came out
were a set of patches to both newlib and libgcc/libstdc++ to make
these issues thread safe under Miosix, which was my primary concern.

By doing so I came to the conclusion that there are certain parts of
the C/C++ standard library, and even some language constructs in C++,
that require cooperation between the library and the OS to be made
thread safe. One example is stdio, in particular printf from multiple
threads. Before these patches in Miosix it was possible for some parts
of text to misteriously disappear due to race conditions in the stdio
buffers. Another issue is related to throwing C++ exceptions from
mutiple threads, which results in weird creashes if proper
synchronization is not taken care of. The standard libraries need to
call the kernel API for synchronization, and to do so in the lack of
overridable (weak) functions for embedded OSes someone has to provide
patches. On the other hand, if the OS under question lacks some of the
synchronization primitives, I'm afraid there is no real way around it.


> 
> 4\/3!!
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQfvqHAAoJECkLFtN5Xr9frEcH/1EgfRmj6nDfNfmoTzqW1vVD
HjCfll9tid8sa1zmm9VtbJZAkX69QAzuiCH6Vce4yUTxLz6Td8GK3kABeFopnll5
8n8vpP+4R4j2AGSIaYd5kkWfXbH81FmhA4oyDa+r9mcZqiXO1MsixRTBwgWnL3nz
tt7XRIIbbUOfKqcPFDhTauwyF/x9u7TJ6q4D37fklJVn9TNGCKqqX8U6Rn9E9HCI
pGuB1C0j/flpU5NcP3L98iXD7yKMlwvzG/+VY8J1z0KJRum3a66CypP0dXpJ4vpk
RlqXeAGh2jfhBCTMBtDu5vEwqNw5doOShK81iOi2p2mupRuKKLw7tT1FASDv3PI=
=xWjF
-----END PGP SIGNATURE-----