Изпечатай

[gat3way]

Абе човек те дефакто вървят като нишки в рамките на един процес. Цялата тарапана по създаване на нови нишки, премахването им и синхронизацията между тях изисква на някой процесор да се изпълни това, което прави управляващата нишка. Демек не се ли скедюлира тази нишка, операциите със всички останали нишки стоят и чакат докато task scheduler-a благоволи да изпълни нишката, която ги управлява.

Добре, реално погледнато всичките си имат отделни PID-ове и биха могли след създаването си да работят на отделни процесори. Обаче за да работят, всичките им синхронизационни примитиви и всичките операции по създаване/убиване на нишки за да се изпълнят, трябва на някой процесор да се изпълни нишката,която ги управлява. Каквото и да говорим, NPTL е по-добър механизъм това да стане, защото НЯМА нужда такава нишка да се изпълнява, такава нишка няма и ролята и се поема от ядрото.

Добре, това не е точно mxn модел. Определено обаче не е и истинска имплементация на 1:1 модел, всичко зависи от една нишка за всички процеси които имат ендакъв PPID.

[tarator]

Създаването и премахването на нишки не са "чести" събития и не се изпълняват от една определена нишка. Нишката, която се опитва да създаде нова нишка се грижи за синхронизирането с останалите, ако то е необходимо (става с пращане на сигнали). През останалото време нишките си вървят напълно независимо една от друга. Затова и моделът няма нищо общо с н:м.

Между другото дори и при NPTL нишките се синхронизират при setuid и компания. Което е доста малоумно и се случват доста races. Скоро ми се налага да викам директно SYS_seteuid защото ако викам glibc функцията понякога всички нишки забиваха.

[gat3way]

Да, но само една нишка се грижи за синхронизацията между всички останали В смисъл една нишка освобождава lock-а, праща сигнал към менажиращата и тя има грижата да разпрати сигнали до всички останали които спят, за да ги "събуди" и натика в runqueue. Тоест механизма си зависи дали менажиращата нишка ще й се даде процесорно време.

А и добре, създаването и премахването са редки събития, но изчакването на други нишки не е чак толкова рядко

Добре де предавам се, знам че си прав, но пак казвам, че linuxthreads е направен тъпо и при определени положения се държи точно както m:n.

При setuid()....защо?

[tarator]

Кое изчакване точно? Защото mutexes и conditions, които също водят до "изчакване" не се управляват от една нишка.

Няма нужда да се предаваш, ние просто си спорим. Аз не претендирам да знам в подробности linuxthreads преди NPTL защото не ми се е налагало да гледам имплементацията в дълбочина.

[gat3way]

Ммм доколкото аз знам в linuxthreads има нишка, която се занимава със синхронизацията между останалите. Примерно една нишка освободи мутекс, за да "разберат" останалите трябва първо на някой процесор да се изпълни тази нишка и тя да изпрати съответните сигнали към останалите нишки, чакащи този мутекс.

При NPTL, това е премахнато и вместо това има някакъв друг (futex) механизъм при който се избягва посредничеството на една менажираща нишка. За целта има една (споделена) променлива, чиято стойност се използва за целите на локинга. Има дефинирани syscalls за "заключване"/"отключване" и "чакане" на тази стойност да се промени. Ядрото се намесва в цялата картинка така, че когато има повече от една чакаща нишка за един футекс и когато той се "отключи", да събуди някоя определена от тези нишки. Така тарапаната около изпращането на сигнали между нишки и менажиращата нишка се елиминира.

Така не се налага "отключването" и "заключването" да става на цената на това някъде тази менажираща нишка да се изпълни някъде. Защото ако всички нишки (без една) от програмата трябва да изчакат изпълнението на менажиращата такава, за да ги арбитрира, то тогава на практика става същото като при m:n трединга - там нали за да се изпълни някоя нишка, трябва процесът й да се изпълни върху някой процесор.

Обаче аз не си давам сметка, че разглеждам случай в който всички нишки изчакват една да освободи мутекса, което не е задължително и зависи до голяма степен от това какво прави кода.

Значи разглеждам по-скоро един случай, който сигурно е възможно най-лошият (предполагам) в linuxthreads (и при който в NPTL нямаме такъв проблем).