This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Recursive locks? Locking API?
- From: Freddie Chopin <freddie_chopin at op dot pl>
- To: newlib at sourceware dot org
- Date: Wed, 17 Oct 2012 15:21:04 +0200
- Subject: Recursive locks? Locking API?
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...
4\/3!!