public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: =?gb18030?B?uuHDvMDkttTH77Ko?= <370615657@qq.com>
To: =?gb18030?B?bmV3bGli?= <newlib@sourceware.org>
Subject: how to use newlib multi thread safety ?
Date: Tue, 11 Jun 2024 19:05:21 +0800	[thread overview]
Message-ID: <tencent_FB51508F1E8CFC3BEC7A7ACBED11FD224606@qq.com> (raw)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 2150 bytes --]

Sorry to bother you, the maintainer of the newlib library. Our project currently uses Cortex-M55 CPU and also uses the newlib library and FreeRTOS. The cross compilation toolchain uses the arm_gnu_toolchain-13.2. Rel1-x86_64_arm_none_eabi version.&nbsp;&nbsp;
I have a few questions to consult:
1. We configured configUSE-NEWLIB-REENTRANT=1 in FreeRTOS and implemented the following two interfaces:
Void _malloc'lock (struct reent * reent)
Void _malloc_unlock (struct reent * reent)
In this case, is using all interfaces of the newlib library multi-threaded safe? For example, are interfaces such as fopen, fread, fwrite, etc. multithreading safe?&nbsp;
Of course, the newlib library provides some interfaces that end in '_r' and we will also use them? Can this cover all interface threads safely?


2. From the official website of newlib, it can be seen that the following interfaces also need to be implemented:
#Include<lock. h&gt;
struct __lock __lock___sinit_recursive_mutex;
struct __lock __lock___sfp_recursive_mutex;
struct __lock __lock___atexit_recursive_mutex;
struct __lock __lock___at_quick_exit_mutex;
struct __lock __lock___malloc_recursive_mutex;
struct __lock __lock___env_recursive_mutex;
struct __lock __lock___tz_mutex;
struct __lock __lock___dd_hash_mutex;
struct __lock __lock___arc4random_mutex;
Void __ retarget lock init (LOCK_ T * lock ptr);
Void __ retarget lock init recursive (LOCK_ T * lock ptr);
Void __ retarget lock close (LOCK_ T lock);
Void __ retarget lock close recursive (LOCK_ T lock);
Void __ retarget lock acquire (LOCK_ T lock);
Void __ retarget lock acquire recursive (LOCK_ T lock);
Int __ retarget lock try acquire (LOCK_ T lock);
Int __ retarget lock try acquire recursive (LOCK_ T lock);
Void __ retarget lock release (LOCK_ T lock);
Void __ retarget lock release recursive (LOCK_ T lock);


Can implementing only these interfaces ensure the safety of multithreading, or must configUSE-NEWLIB-REENTRANT=1 be configured simultaneously, and both hook functions of malloc must be implemented, while also implementing all interfaces in 2?
Thank you very much for your answer

                 reply	other threads:[~2024-06-11 11:05 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=tencent_FB51508F1E8CFC3BEC7A7ACBED11FD224606@qq.com \
    --to=370615657@qq.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).