This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, newlib] Allow locking routine to be retargeted


----- Thomas Preudhomme <thomas.preudhomme@foss.arm.com> schrieb:
> On 10/11/16 20:32, Freddie Chopin wrote:
[...]
> > This could work, if only malloc() was not protected with the statically
> > created _LOCK_T lock itself, which would need such initialization
> > too... I don't see any other way to write such function for an RTOS
> > which has mutexes with size greater than "uintptr_t" (probably huge
> > majority). You could do it with a static pool of storage for mutexes,
> > but then you'd have to know upfront how many you want and your RTOS
> > would have to allow creation of locks in provided storage (most of them
> > allow that, but not all). Maybe I just don't see the simplest solution
> > to this problem?
> 
> Why do mutex needs to be more than a single integer? How big are mutex in RTOS 
> typically in your experience?

This depends on what features the RTOS wants to support.  For example SMP, locking protocols, blocking on a wait queue, user-provided or external-provided storage, nesting, etc.

For RTEMS a recursive mutex with support for priority inheritance (or OMIP) and SMP (optional) needs 20 bytes on a 32-bit machine for example:

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/sys/rtems/include/sys/lock.h;h=e0d77cb614b348a949e23ca4c543b1ce6a055b6d;hb=HEAD#l55

With an integer only you can implement a futex like on Linux, however, this needs a complex infrastructure in the background and provides only random fairness.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]