Hi,
Thanks for pointing that out, basically the same issue I face.
First I thought it would be simple to fix OR wrap around the usage of
SEM_INITIALIZER/NXSEM_INITIALIZER/NXMUTEX_INITIALIZER. My assumption was
that they are not used in very many places in user space. For wrapping
one option would be to do a lazy init of the semaphore when sem_wait() /
sem_post() / etc. are called and identify the non-init state by some
special flagging.
However I'm totally wrong, PTHREAD_MUTEX_INITIALIZER exists as well and
this is used to initialize the semaphore in pthread_mutex_t and
pthread_cond_t. Trying to get rid of the initializer macro proves to be
too much re-factoring of code I'm not very familiar with (big risk
something will break) -> I'll try to figure out something else.
Br,
Ville Juven
On 26.4.2023 12.53, Petro Karashchenko wrote:
Hi,
Some time ago I tried to fix this with
https://github.com/apache/nuttx/pull/6376 but it ended-up nowhere as I
didn't find time for a proper solution.
Best regards,
Petro
ср, 26 квіт. 2023 р. о 12:50 Ville JUven <ville.ju...@gmail.com> пише:
Hi,
I'm in the process of trying to fix this issue:
https://github.com/apache/nuttx/issues/8917
TL;DR semaphores are unusable when MMU is in use, because the kernel
private data of struct sem_s exists in user space and is not always
visible to the kernel when it needs it. So I'm trying to separate / move
the kernel private data to kernel space (for CONFIG_BUILD_KERNEL only
btw.).
I have a question about using mutex_t / struct mutex_s inside libs/libc.
The mutex_t definition is kernel internal but some modules inside the
libs folder use it directly. My question is, is this intentional ? I
don't think such modules should be using mutex_t.
Why not ? libc is userspace code (even though we use it inside the
kernel as well as I guess nothing prohibits this)
What is the problem ? Using NXMUTEX_INITIALIZER uses the kernel private
NXSEM_INITIALIZER macro. I'm trying to separate kernel private data from
semaphores like stated above but there are some corner cases where this
becomes impossible, mutex_t is one example.
The locations where mutex_t is used (there might be others, using
nxrmutex for example):
./libs/libnx/nxmu/nx_connect.c:55:static mutex_t g_nxliblock =
NXMUTEX_INITIALIZER;
./libs/libnx/nxfonts/nxfonts_cache.c:79:static mutex_t g_cachelock =
NXMUTEX_INITIALIZER;
./libs/libc/locale/lib_gettext.c:87:static mutex_t g_lock =
NXMUTEX_INITIALIZER;
./libs/libc/wqueue/work_usrthread.c:65: NXMUTEX_INITIALIZER,
./libs/libc/userfs/lib_userfs.c:73:static mutex_t g_userfs_lock =
NXMUTEX_INITIALIZER;
./libs/libc/stdlib/lib_mktemp.c:68:static mutex_t g_b62lock =
NXMUTEX_INITIALIZER;
My question ? Should these be sem_t or perhaps pthread_mutex_t ? Both of
which are valid user APIs.
Anyone have any idea / suggestions on how to fix this ?
Br,
Ville Juven / pussuw
