• dez
    #128
    "Hol javítottál ki? Nem látom."

    Kezdem azt hinni, hogy nálad nem jelenik meg minden hozzászólás... ;) Pl. #120.

    "Persze, de ettől még a probléma nem oldódik meg."

    De az a megoldás kulcsa. És lássék: a #106-os alapján egy program két threadje is futhat más-más procin is akár. De persze lehetséges, hogy itt téved a Wikipedia. (De semmiképp sem biztos.)

    "Akkor meg kéne különböztetni a thread-et mint fogalma, és mint adatszerkezetet (process dettó)."

    Csak annyit kell tudni, amit a #115-ben leírtam, de adja is magát. Persze laikusoknak így kevésbé egyértelmű. Csakhogy, a programozási fogalmakat alapvetően a programozóknak találták ki, nem a laikusoknak.

    "Implementációs kérdés, hogy a regiszterek thread-enként vagy process-enként mentődnek."

    Tessék? Csak akkor lenne elég processenként menteni, ha annak esetleges több threadjét nem akarjuk (preemptív) multitaskban futtatni.

    "Az első esetben nem kell child process, a másodikban kell."

    Ez igaz, de itt most a desktop OS-ekről beszélünk (azon belül Windowsról), nem valami egyszerűsített embedded rendszerről.

    "Win-en elég egy új thread-et fellőni (AfxBeginThread), másra nincs szükség (vagy elintézi az OS magában)."

    Nyilvánvaló, hogy az OS intézi ezeket. Mit gondolsz, ha nem mentené/töltené a Windows (a szálhoz tartozó stackbe) a regiszereket taszkváltáskor, mi lenne velük? Az AfxBeginThread paraméterei között szerepel is a StackSize.

    Viszont... Kicsit jobban utána néztem én is a thread-témának, és azt találtam, hogy van (OS-től föggően is), amikor általánosságban használják a kifejezést (lásd pl. #118), mint fogalom, és van, amikor konkrétan (egy processen belüli függvény threaddá avatása, saját stackkel, handle-lel, stb., és külön szálon futtatása, a la AfxBeginThread)... Ez persze okozhat némi félreértéseket. Rigidus is nyilván az utóbbira asszociált. (De azért 1-2 dologban tévedett.)

    Találtam egy érdekes oldalt:
    Idézetek:
    "Threads are "lightweight processes." They behave like processes in that they support an additional path of execution, but they share the same address space as their parent. Because there is only one address space, there is little need to think about IPC. It also means that a programming error in one thread can ruin data in the other thread."

    És ami főleg érdekes:
    "Microsoft introduced cooperative multitasking (which Microsoft refers to as process multitasking) in Windows 3.0. The newest versions of Windows (Windows NT and Windows 95) include preemptive multitasking (but only between the threads of a given process)."
    Wow...

    Na mindegy, szerintem tudhat futni egy process két threadje két külön procin is.