newlib-nano malloc locking

Furthermore, what's the status of reentrancy in general in newlib-nano?

Look into the implementation, lock/unlock atomic operations are disabled right now, but I think it would be trivial to bring it back. The only problem is we don't have the multi-thread environment to test it. Maybe you can help on this issue (i.e., test the lock/unlock operations in newlib-nano/malloc in your environment).

Yes, any patches are welcome, on condition that the license are followed.

Thanks.

About newlib-nano status, it is under review for upstreaming. Please refer to: http://sourceware.org/ml/newlib/2013/msg00368.html

Thanks - Joey

I don't see anything about reentrancy in general at that link. Am I missing something?

Freddie Chopin showed concerns same with you in that thread.
Could you rebuild newlib-nano (or the whole toolchain) to enable lock/unlock and give it a try in your system? The multi-thread support can be enabled by changing below macros in mallocr.c:

/* Disable MALLOC_LOCK so far. So it won't be thread safe */
#define MALLOC_LOCK /*__malloc_lock(reent_ptr) */
#define MALLOC_UNLOCK /*__malloc_unlock(reent_ptr) */

Thanks.

Yeah, I'll give it a try tomorrow if I get a chance. I don't really anticipate any problems.

Thanks.
Please ask if there is any question about the toolchain.

Sorry, I haven't gotten to this yet. The malloc stuff should be no problem, assuming all you did was redefine those macros to not call anything, and that they're still in the right places and so on.

I was asking earlier about the state of reentrancy in newlib-nano in general. Like for printf, for example. Do you have any information about that? Should it "just work"? My first glance seems to indicate that it might be seriously broken...

Any information will be helpful, thanks!

Sorry that we don't have very much information about reentrancy of printf. It is implemented for small devices with very limited memory in the first stage of work, and we haven't paid much attention to its reentrancy yet. So it's possible the reentrancy of printf is broken.

Nevertheless, it is planned to keep improving Newlib-nano, and making it reentrant would be a good point to go. Any feedback or comments here will be highly appreciated. Thanks.

I don't really see how a non-thread-safe c library is of much use to anybody doing a project of any reasonable size. I mean, I get where you're coming from, but if newlib already had support for being thread-safe, why did you take it out when doing this slimming process? Even just a global c library lock would be ok for now.

I think my plan is going to be to use newlib-nano, but shim all the calls with OS locks to be safe. It's going to be gross, but it beats doubling the code size to include the full-size newlib.

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

__malloc_lock() and __malloc_unlock() are still commented out in the latest releases.
Is there any reason for this ?

Beside, since these symbols are weak, I don't understand the need for not calling them from the libc.
If the libc user doesn't implement threads, then he could just not implement these functions.

There is not knowning reason not to do that. What's needed is a patch to remove the comment, appropriate test and sending out to newlib upstream for approval.

Contribution are high welcomed.

Just a short heads up:
This issue has indeed been fixed in recent releases of newlib nano:
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=2665915cfc46aa6403bb2efd473c523d3167e0cb

As of this writing, the current toolchain already incorporates it.