On 4/6/2023 9:09 AM, Petro Karashchenko wrote:
Also pthread_mutex is a solution for user space, but would be good to
have something similar for kernel space.
During adding nxmutex wrapper to the code many misuse issues were
identified, so it is adding safety during coding and does not allow
misuse. Of course a binary semaphore is a solid building block, but
leaving it alone just increases the probability of errors in code.
Otherwise POSIX would not add pthread_mutex and would extend
semaphores. I mean that the need of it seems to be obvious since
pthread_mutex are a part of POSIX side by side to semaphores and it
would be good to have something like pthread_mutex for kernel.
That is not a very compelling argument.
All of the pthread interfaces exist only because they operate on
pthreads and require pthread_t to identify the pthread. The pthread IDs
only exist within a "process."
semaphores have no inherent identification associated with them and have
a global scope that can work across different "processes."
There are no "processes" in NuttX; we emulate them in the FLAT build
with tasks. A task is just a thread.
In NuttX, we use "heavy weight" threads: A pthread is really the same
as a task; it bound to the task group only via the shared group_s
structure. It is all smoke and mirrors to get POSIX compatibility.
Underneath, a pthread and a task is the same; a mutex and a semaphore is
the same. Trying to make distinctions internally when there are none
cannot lead to good design decisions.
[Linux, uses light weight threads which are something very different]
Trying to force them to be different is very artificial. It is similar
to the artificial designation of some task as threads. But at least that
was done to meet the functional interface specification. Mutexes are,
similarly, just semaphores. Again the exist only to meet POSIX
requirements for pthread interfaces to go with the fake pthreads. There
is absolutely no reason to make some implementation distinction between
them other than to meet the letter of the POSIX requirement.
Building another fake internal infrastructure does not seem like
something that is in our best interest.
