...

The real reasons in this case is (1) it is inappropriate, and (2) it is incompatible with the PROTECTED and KERNEL builds where pthreads cannot be supported.

Why inappropriate?  Because..

pthread Interfaces Are User Interfaces

...

The KERNEL build, on the other hand, uses a Memory Management Unit (MMU) to create a virtual address space in which which there is still a separate protected kernel address space, but many user address spaces for user programs. These are usually called processes. This is the family familiar build model that you find with high-end Unix-like systems such as Linux.

See Memory Configurations for additional information

Address Spaces

...

, Memory Allocators, and User Mode

What would happen if you tried to create a pthread in the PROTECTED or KERNEL build? The effect of these address space differences become very pronounced. pthreads are, by their very definition, user-space threads. That means that the OS will attempt to create a user-space environment for the pthread: The thread's stack and other resources.

And when the pthread is started, it will be started in user mode, not kernel mode.

It would require a significant change to the OS to alter that behavior and that is not under consideration (because the change is also inappropriate).

...

Because the application space and the kernel space are separately built and separately linked in the PROTECTED and KERNEL builds. No application addresses are known by the kernel and no kernel addresses are known by the application (applications interface via system call traps, not C function calls). So what address would the kernel thread provide for the pthread entry point? A known kernel space address? Of course, the system would crash with a memory fault immediately if a protected address were executed in user mode.

...

Okay, so there are no kernel pthreads. But could other pthread resources be usable in the kernel. The short answer is no. Consider mutexes, for example. By definition, a mutex can only be used within threads of the current process (or task groups as they are often called in NuttX). They have no meaning outside of the task group. Since the kernel thread "task group" can have no pthreads, how could these mutexes be used under the proper standard definition of what a mutex must be?

This is true of all pthread interfaces:  None of the pthread interfaces were intended from inter-process communications; only for inter-pthread communications within the same process (task group).

Roadmap

As alluded to before about the appropriateness of pthread in the OS. There is a roadmap for these kinds of features. That roadmap is to continue to conform strictly to the standard OS definitions of Opengroup.org and to continue to evolve as a fully compliant, very standard, tiny Unix-like operating system.

• Part of this is getting all user interfaces out of the OS.
• Another part is migrating all pthread support out of operating system and into the user-facing C library.
• An additional objective on the roadmap is to streamline the kernel threads and to disconnect them from task groups.  Kernel threads should not be part of any task group.

In regard to this last point, the following is taken from From Apache NuttX Issu Issue 1108: "Remove streams from Kernel Threads":

No Streams in Kernel Threads

...