>У Вас те же проблемы, что и у первого оратора. Вы не
>понимаете где разница между епархией ядра и нитевой библиотеки (рискну предположить,
>что даже не представляете архитектуры планирования Linux, иначе бы давно уже
>проассоциировали thread group id(AKA tgid) с process id (aka pid)).

У меня как раз проблем нет...
И с чего это вы решили, что можете заключать, кто и что "не понимает"?
Я годами использую POSIX модель thread в своих кодах для realtime & embedded оборудования, и как раз здесь, в стандартизованной модели - проблем нет...
А "архитектуру планирования Linux" я и вправду - "даже не представляю"... она мне нафиг неинтересна, до тех пор, пока она будет "самопальщиной"!

>Обладатель торговой марки UNIX не определяет "степень like" - тут или да
>или нет. Насколько я помню, сертифицированы Solaris, AIX и SCO UNIX.
>Остальные просто напросто не пройдут тесты, поскольку не удовлетворяют
>SuS в должной степени.

Фигня это. И не нужно смущать дезинформацией неокрепшие умы:
- "Обладатель торговой марки" - это кто? SCO?
- так вот, не так давно закончилась тяжба, в которой Open Group (известный ранее как X-консорциум) доказал, что даже марка UNIX принадлежит 2-м субъектам в равной мере SCO & Open Group. Почитать можно здесь, например:
http://www.kuzbass.ru:8083/docs/sus2/mindex.html
- и с какой это стати, и на каком основании SCO вообще вправе "сертифицировать" нечто, на соответствие SCO UNIX? На том только основании, что им ЭТО перепало после многочисленных перепасовок, да и то не первой свежести?
- и потом: "сертифицированы" - каким документом? Ссылки в студию!
- да и перечисленные вами "Solaris, AIX и SCO UNIX" - это всё линия SVR4 - а что, вся линия Беркли, в которой существенного для UNIX было сделано во много крат более - так её что, не существует?
- а вот стандарты Open Group, они же известны как UNIX95, UNIX98 - и очень плотно взаимодействуют при разработках с POSIX - вот они являются определяющим местом "что есть UNIX".
- и именно стандартизация POSIX/UNIX98 и делают мир UNIX-like тем, чем он есть, с переносимостью и возможностью портирования кода...
- и единственное интересное место во всей истории развития Linux - это то, что они во всём следовали традициям и стандартам UNIX (утилиты, API...), которые к тому времени уже да-а-а-авно устоялись - следовали, даже "наступая на горло своей песне"...
- следовали бы они какой-нибудь BeOS да ещё с потугами сделать "самую лучшую из OS"... где бы сейчас был тот Linux?

>Разные адресные пространства -- разные экземпляры переменных.
>Их нет неободимости синхронизировать.
Кроме тех областей, которые используются для IPC.

>Не только: она возникает для всех потенциально совместно используемых >глобальных (в смысле те, которые не в стеке) структур/переменных,
>которые и являются источником трафика по шине, обеспечивающей эту
>когерентность.
thread-ы, в свою очередь могут аккуратно использовать технику экземпляров данных - всё, что связано с pthread_key_*()...

Т.е. проблемы некогерентности в SMP могут возникать как в тех, так и в других случаях...

С другой стороны - в некоторых ситуациях fork()/pthread_create() реализации по производительности, точнее даже по "времени латентности" (что ещё хуже - именно в те короткие интервалы, когда от них и ожидают активности) - могут отличаться на 1-2-3 порядка!
Я как-то такой тестик сделал... он "разошёлся" по Internet, вот 1 из URL - захотите - посмотрите: http://www.winsov.com/ci003.php.

P.S.
>Самафор в SMP -- это скорее всего программная обертка функциональности, >предоставляемой железкой. По этому тут о какой-то когерентности говорить >можно, но она не будет иметь ничего общего с тем, о чем мы говорили
>изначально.
Зачем - простейшие синхронизаторы: мютекс + семафор - вполне достаточно переменной, над которой выполняются неделимые операции INC/DEC - только сделайте её доступной процессам/потокам.