From: Thomas Preudhomme <thomas.preudhomme@foss.arm.com>
To: newlib@sourceware.org
Subject: Re: [PATCH, newlib] Allow locking routine to be retargeted
Date: Wed, 23 Nov 2016 14:38:00 -0000 [thread overview]
Message-ID: <7dc33ad1-fecf-a0ec-81b6-2db698c5c57d@foss.arm.com> (raw)
In-Reply-To: <707976084.18201.1478865372907.JavaMail.zimbra@embedded-brains.de>
Hi Sebastian,
I was thinking on how to solve this issue and found two possible solutions:
1) select size of lock at configure time
Instead of being an enable/disable option the configure option could take an
integer value N that determine the size of lock, default being the size of a
pointer. The lock would then be defined as an array of N integers.
Pro: LOCK_INIT works, simpler & smaller change
Cons: lock needs to be as big as the biggest lock among all the platforms you
want to target wasting a bit of space.
2) Remove static initialization of locks
Remove all LOCK_INIT and add code as required to call lock_initialize at start
up time.
Pro: you only pay the size for the lock you need (ie nothing except empty
functions in the single threaded case)
Cons: much bigger work, start up cannot support multithread
I'm more in favor of 1) because that's good enough for us and the change is
smaller in scale but I want to make sure that's good for your use case as well.
Best regards,
Thomas
On 11/11/16 11:56, Sebastian Huber wrote:
>
> ----- 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.
>
next prev parent reply other threads:[~2016-11-23 14:38 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-10 14:42 Thomas Preudhomme
2016-11-10 15:34 ` Freddie Chopin
2016-11-10 16:05 ` Thomas Preudhomme
2016-11-10 20:32 ` Freddie Chopin
2016-11-10 20:35 ` Freddie Chopin
2016-11-11 9:38 ` AW: " onkel.jack
2016-11-11 11:01 ` Thomas Preudhomme
2016-11-11 11:20 ` onkel.jack
2016-11-11 12:13 ` Freddie Chopin
2016-11-11 11:09 ` Thomas Preudhomme
2016-11-11 11:54 ` Freddie Chopin
2016-11-11 11:56 ` Sebastian Huber
2016-11-11 13:40 ` Thomas Preudhomme
2016-11-11 14:10 ` Freddie Chopin
2016-11-23 14:38 ` Thomas Preudhomme [this message]
2016-11-23 15:52 ` Freddie Chopin
2016-11-24 7:44 ` Sebastian Huber
2016-11-24 8:29 ` Freddie Chopin
2016-11-25 10:21 ` Thomas Preudhomme
2016-11-25 12:04 ` Thomas Preudhomme
2016-11-25 12:35 ` Sebastian Huber
2016-12-13 17:20 ` Thomas Preudhomme
2016-11-25 14:12 ` Freddie Chopin
2016-12-13 17:18 Thomas Preudhomme
2016-12-13 20:13 ` Freddie Chopin
2016-12-14 11:54 ` Thomas Preudhomme
2016-12-14 12:39 ` Freddie Chopin
2017-01-11 13:09 ` Thomas Preudhomme
2016-12-13 21:11 ` Freddie Chopin
2016-12-13 21:41 ` Freddie Chopin
2016-12-14 14:22 ` Sebastian Huber
2016-12-14 14:36 ` Thomas Preudhomme
2016-12-14 14:52 ` Thomas Preudhomme
2017-01-09 18:49 ` Freddie Chopin
2017-01-10 16:50 ` Thomas Preudhomme
2017-01-10 17:07 ` Freddie Chopin
2017-01-11 16:09 ` Thomas Preudhomme
2017-01-11 16:46 ` Craig Howland
2017-01-11 17:48 ` Thomas Preudhomme
2017-01-11 18:08 ` Craig Howland
2017-01-11 19:14 ` Freddie Chopin
2017-01-12 10:52 ` Thomas Preudhomme
2017-01-12 16:20 ` Freddie Chopin
2017-01-12 16:55 ` Thomas Preudhomme
2017-01-13 11:25 ` Thomas Preudhomme
2017-01-13 13:24 ` Thomas Preudhomme
2017-01-13 18:05 ` Freddie Chopin
2017-01-13 18:16 ` Thomas Preudhomme
2017-01-16 15:59 ` Thomas Preudhomme
2017-01-20 13:37 ` Thomas Preudhomme
2017-01-20 13:55 ` Freddie Chopin
2017-01-24 10:00 ` Freddie Chopin
2017-01-25 12:31 ` Corinna Vinschen
2017-01-30 10:51 ` Thomas Preudhomme
2016-12-14 15:27 ` Freddie Chopin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7dc33ad1-fecf-a0ec-81b6-2db698c5c57d@foss.arm.com \
--to=thomas.preudhomme@foss.arm.com \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).