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: AW: [PATCH, newlib] Allow locking routine to be retargeted


On Fri, 2016-11-11 at 12:19 +0100, onkel.jack@t-online.de wrote:
> To build multithread for running singlethread seems not to make sense
> to me.

I think that the only thing that is changed with the "multithreaded"
enable switch are the locks, so with this change you could really use
"multithreaded" variant of newlib for singlethreaded application with
no issues (apart from a minor size increase).

> On the other hand, bare metal could implement some threading model
> without undergoing the pain to put another OS implementation into
> newlib.
> In fact I'm doing so at the moment by patching lock.h (not a good
> solution through).

Yes, that would be great indeed. I had a plan to just drop whole newlib
into my RTOS and patch lock.h for my needs.

> I figured out in practice, building newlib for multithread with no
> locks implemented just lead to a binary that will crash if malloc
> will be used concurrent. I would consider this as a formal bug first
> hand.  

This is not entirely true. In case of malloc (and also time-zone info)
you don't actually need to have proper lock.h. All you need to do is to
reimplement __malloc_lock() and __malloc_unlock() functions. This is
what I've done in my RTOS for now and this works well. The mutex used
by these two functions is a global object initialized manually before
main() starts (and before global constructors).

https://github.com/DISTORTEC/distortos/blob/master/source/syscalls/malloc_unlock.cpp#L27
https://github.com/DISTORTEC/distortos/blob/master/source/syscalls/malloc_unlock.cpp#L27
https://github.com/DISTORTEC/distortos/blob/master/source/memory/getMallocMutex.cpp#L38
https://github.com/DISTORTEC/distortos/blob/master/source/scheduler/lowLevelInitialization.cpp#L106

This has a "small" problem, that it only makes malloc() and free()
usable in multithreaded scenario, but leaves everything else vulnerable
(like FILE objects)...

> So any improvement would be highly welcome.
> I will try to build a proposal solution next days. 
> Only problem I see there is the typedefs in lock.h.

I think that if _ALL_ locks in newlib would be created with functions -
so with __lock_init() instead of the _LOCK_INIT() macro - this would
make the implementation of such overrides much simpler. On the other
hand you'd have to somehow call initialization functions for global
locks before your application starts...

The other viable option is to leave "dynamic" locks as is (so the lock
created with __lock_init() stay exactly as now) and provide functions
like __malloc_lock() / __malloc_unlock() for _ALL_ global locks. This
way the typedefs in newlib could be a pointer and using these functions
for global locks would allow them to be overriden in your project. From
a quick look it seems there are 8 global locks in newlib (telldir, 2x
findfp, time-zone info, malloc, atexit, environment, quick atexit). For
two of them we already have such functions (malloc and time-zone info).

Regards,
FCh


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