egyes processek közös címtartományban vannak, és osztoznak egyes erőforrásokon
Ez éppen úgy igaz az ISR-ekre is, a kernel "processz" részei, közösen a higher-half címtartományban, egymástól függetlenek és osztoznak bizonyos erőforrásokon.
talán ez is elég ahhoz, hogy megállapítsuk, hogy pl. a hw-interrupt az nem process/thread, mivel nincs alávetnek az ütemezésnek
A pthread sincs POSIX szabvány szerint. Simán elfogadott, hogy pusztán felhasználói módban váltogatnak a szálak, saját ütemezővel, a kernel ütemezője még csak nem is tud róluk.
Nagyon sokáig a Linux sem tudott kapcsolni pthread szálak között, az viszonylag új fejlesztés (valahol 2.4 körül került be, előtte nem volt), valamint az első musl implementációknál is a pthread_create nem hívott syscall-t, hanem maga kezelte a szálak altatását/felébresztését/ütemezését, így a kernel ütemező nem is tudott a pthread szálakról ott sem. Mégis multithreading-nek nevezzük a pthread-et ezeknél az implementációknál is.
(ps1.: a legújabb musl már a SYS_sched_setscheduler rendszerhívást használja, akárcsak a glibc, és a saját _wake, _wait stb. funkciója opcionális.)
(ps2: ugye a lényeges különbség csak multicore esetén jön elő; ha a kernel nem tud a thread-ekről, akkor csak az adott processzhez tartozó összes thread-et egyszerre tudja átköltöztetni egyik magról a másikra, míg ha a kernel ütemező tud róluk, akkor optimálisabb a kihasználtság, hisz minden thread-et külön magon képes futtatni. Amíg egymagos processzorok voltak a jellemzőek, addig nem is volt fontos, hogy a Linux kernel maga ütemezze a szálakat, addig bőven elég volt, hogy a libc kapcsolgatta őket pusztán felhasználói módban, hiszen egyszerre úgyis csak egy utasítást tudott végrehajtani a CPU.)