Recursive locks? Locking API?
Sun Oct 21 10:25:00 GMT 2012
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...
More information about the Newlib