Как обстоят дела с многопоточностью в других uCLinux и других embedded ОСях?

появилось в 1996 (имплементация Xavier Leroy), начиная с версии ядра 1.2.x и libc 4.x, инклюд <pthreads.h>. Это и набор системных вызовов (clone) и несколько юзер-спейс реализаций (linuxthreads/posixthreads/nptl/etc). Многопоточность имеет смысл для масштабирования, то бишь в многопроцессорных системах, к которым uclinux, насколько мне известно, не относится. При вопросах портирования можно выкрутиться юзер-спейс реализацией.

Спасибо.
В ядре 2.6 ничего в этом плане не поменялось?
У меня сейчас 2.4.17 и glibc-2.3.1 для arm. Нашел реализацию pthread. Система однопроцессорная, в принципе, наверное без разницы, как реализовано, лишь бы работало нормально. Просто использование потоков мне кажется более удобным, чем создание кучи процессов, а затем разделяемой памяти для них - в рамках одного модуля приложения.

Кстати в свете новых веяний треды (openmp) как парадигма параллельного программирования уже устарели.

eCos - многопоточный, но не многопроцессный - threads - родные, есть posix-надстройка.
QNX - и процессы, и потоки, posix.
Что в более мелких - сейчас не помню.

Процессы и потоки выдумка Linux-а.
Там процессы настолько медленно переключаются, что пришлось придумать потоки.
В без MMU-ушных процах в RTOS процесы и потоки это одно и тоже и называются обычно задачами.

В большинстве книг по Linux не упоминается Posix thread library - вызовы с префиксом pthread_

Однако я встречал упоминание, что в последних версиях Linux это реализовано. Начиная с какой версии?

Это отдельная библиотека, или набор системных вызовов? В каком хедере описаны?
Как обстоят дела с многопоточностью в других uCLinux и других embedded ОСях?

Можно сказать во всех с ядром 2.6 и glibc >= 2.3.x, Насчет старых дистров с ядром 2.4 , не могу сказать точно, если есть, то бэкпортированно из 2.6 (у RHEL в особенности).


POSIX Threads в линуксе "работают" в ядре, интерфейс пользователя в библиотеке libpthread, хэдэр <pthread.h>, линкуется соответственно через -lpthread. Всё описано в документации glibc.

Насчет uCLinux & co, Вам ничего сказать не могу, к сожалению никогда их не использовал

Процессы и потоки выдумка Linux-а.
Там процессы настолько медленно переключаются, что пришлось придумать потоки.
В без MMU-ушных процах в RTOS процесы и потоки это одно и тоже и называются обычно задачами.

А что сейчас с веяниями? Как параллельные проги "правильнее" делать?

А точнее так: в ядре 2.4 были только процессы и все потоки с точки зрения ядра предствлялись процессами (только имели общую разделяемую память) с разными PID ами что можно было видеть соответствующими утилитами.
В 2.6 появилось native thread тоесть поток как сущность на уровне ядра. Соотвественно создание потока стало менее ресурсоемким.

Патч обеспечивающмй native thread в ядре существует, боюсь наврать, но он вроде не бэкпортированно из 2.6, а развивался сам по себе и в 2.6 просто его включили окончательно.

Threads are a popular modern programming abstraction. They provide multiple threads of execution within the same program in a shared memory address space. They can also share open files and other resources. Threads allow for concurrent programming and, on multiple processor systems, true parallelism.

Linux has a unique implementation of threads. To the Linux kernel, there is no concept of a thread. Linux implements all threads as standard processes. The Linux kernel does not provide any special scheduling semantics or data structures to represent threads. Instead, a thread is merely a process that shares certain resources with other processes. Each thread has a unique task_struct and appears to the kernel as a normal process (which just happens to share resources, such as an address space, with other processes).

This approach to threads contrasts greatly with operating systems such as Microsoft Windows or Sun Solaris, which have explicit kernel support for threads (and sometimes call threads lightweight processes). The name "lightweight process" sums up the difference in philosophies between Linux and other systems. To these other operating systems, threads are an abstraction to provide a lighter, quicker execution unit than the heavy process. To Linux, threads are simply a manner of sharing resources between processes (which are already quite lightweight)[11]. For example, assume you have a process that consists of four threads. On systems with explicit thread support, there might exist one process descriptor that in turn points to the four different threads. The process descriptor describes the shared resources, such as an address space or open files. The threads then describe the resources they alone possess. Conversely, in Linux, there are simply four processes and thus four normal task_struct structures. The four processes are set up to share certain resources.

[11] As an example, benchmark process creation time in Linux versus process (or even thread!) creation time in these other operating systems. The results are quite nice.

Threads are created like normal tasks, with the exception that the clone() system call is passed flags corresponding to specific resources to be shared:

clone(CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND, 0);

The previous code results in behavior identical to a normal fork(), except that the address space, filesystem resources, file descriptors, and signal handlers are shared. In other words, the new task and its parent are what are popularly called threads.

2 makc Извеняюсь, что наврал..
хоть и появились ktread_* в <linux/kthread.h>, но, действительно, kthead_create возвращает task_struct..