Desktop aplikacije večinoma niso multithreaded???

Okay, morate se zment, kaj me zdaj sprasujete. V L-ju (zgoraj opisano) ima vsak objekt (kot v javi) svoj thread. Ker se da preklope med taski izvesti kot funkcijske klice, kot najhitrejsa varianta, je to cisto ok.

Zdaj, ali pa se da s takim programiranjem (glej jezik L) opisati vse mozne paralelne programe je pa vprasanje. To trenutno raziskujem. Recimo, ali se da nekako "simulirati" mutex/semafor/condvar./rw-locki/... v L-ju.

Dejstvo pa je, da L v sami osnovi prepreci:
- deadlocke
- race
- izjemno omili starvatione (ce pride do njega, se ga da ocitno nedvoumno razresiti)

Malo subjektivno: zelo olajsa izkoriscanje dane paralelnosti

Je pa res, da nisem celotnega L opisal, je podana samo osnovna ideja. Nisem opisal vseh trikov, predvsem memory protection med taski. Sharanje podatkovnih struktur je nujno na tako finem paralelizmu.

Se nisem nekaj časa oglasil. Ja, sem družboslovec, sem šel na FDV, samo v gimnaziji sem delal OS, ki bi taske razdelil več kompjutrom v mreži. Zato pa sem takrat dobro spoznal assembler in sistemsko programiranje (CR0, paging, TSS, GDT, LDT, DR0-7 itd., segmentne selektorje). No, OSa nisem nikoli dokončal, ker mi je preveč časa vzela izdelava assembler-->machine language prevajalnika.

Je pa ena prednost, če razmišljaš v zbirniku - vedno ti gre po glavi RDTSC (Read Time-Stamp Counter). Vedno se vprašaš, 'koliko košta' nek programski konstrukt.

Jaz tistega o L-ju nisem preveč dobro razumel: kar se tiče mene je simetrično procesiranje (simetrično=skupen memory+IO) enako TSS+APIC v okviru MultiProcessor Specification 1.4

'for_TS' ali 'for_parallel': vseeno, samo tu ni bistveno, da se paralelno izvaja, pomembno je, da se LAHKO paralelno izvaja.
Pomembno pa je tudi označiti, katere spremenljivke (memorijske lokacije) so 'common' (tj. prostor za shranjevanje rezultatov); alternativno se lahko shranjevanje rezultatov izvede preko funkcije tipa shrani(oznaka iteracije,rezultat).

64202, je pa res, da bi, če bi hoteli imeti učinkovito izvajanje - ta stvar morala biti podprta v OS. Bi bilo zanimivo se igrati z Solaris AMD64 kernelom... Razlikovanje med lightweight in heavyweight ne bi bilo več pomembno za programerja.
Ob koncu vsake (tretje) iteracije je lahko RDTSC benchmark - če je dolgo (10 milijonov ciklov oz. kako stotinko sekunde), potem se izvajanje zanke prenese še na ostale procesorje. Ampak tu skoraj ni kazni, saj če je OS pravilno sprogramiran se v schedule_queue od ostalih procesorjev samo vrine adresa od TSSja.
RDTSC Benchmark ima tudi prednost, saj če se ugotovi, da je povprečno izvajanje ene iteracije dolgo nekaj sekund - se izvajanje taska že splača prenesti na ostale procesorje v HPC clustru. Poleg časa lahko tak benchmark prešteje tudi količino RAMa, ki je bila prebrana in količino RAMa, ki je bila zapisana (s pomočjo paginga se vse strani označi READ&WRITE only, potem pa se prešteje število PAGE faultov.

bi rad z interneta downloadal programe, ki ti bodo vsak gumb na dialogu risali v drugem threadu?

Vrstni red naj ne bi bil pomemben, v debug modu pa lahko nastaviš, A) da so vse ne-common spremenljivke ob začetku iteracije nastavljene na vrednost, kot je bila pred začetkom zanke B) da pustiš zanko izvajati normalno. Rezultat mora biti z enakimi podatki enak v obeh primerih. Ja, če bom imel čez par let multicore hyperthreaded procesorje, potem hočem, da programi (ki jih downloadam z neta) to uporabljajo.

Vesoljc pravi:

kar bi "mi" radi je prednost nitk, ampak brez njih samih

Ma ja, saj zato pravim, da rabimo nekaj preprostega in učinkovitega; učinkovitega v smislu RDTSC. Pa saj - lepo označiš kodo, ki je 'thread safe', OS loop controller pa se odloči na koliko procesorjev bo dal izvajanje zanke (samo en, dva ali več). Pa še lažje je določiti 'prioriteto' procesu, saj tudi pri računsko intenzivnih nalogah ni potrebno krasti kontrole programu s pomočjo urnega interrupta, pač pa mu jo lahko OS lepo vzame ob ponovitvi zanke.

No ja, kar sem mislil s tem povedat je, da je treba pri teh zadevah razmišljat v asemblerju s pogledom na TSS in CR3, višjejezikovne konstrukte pa se prilagodi čimbolj učinkoviti/lepi implementaciji.

No ce ze toliko razmisljas v assemblerju, potem bi lahko vedel da ti tako izvajanje for zank na vec procesorjih ne prinasa koristi. Se vedno moras dostopati do istega dela pomnilnika kot sicer in to je pri takih enostavnih zankah tudi edino ozko grlo. Vec procesorsko izvajanje je torej primerno predvsem za procesorsko intenzivne zadeve (ojej, kdo bi si mislil) in tam pridejo niti cisto prav, ker jo enkrat ustvaris in potem pustis laufat po svoje, OS se pa odloci na katerem CPUju bo tekla. Da bi ti tu kompajler kaj sam caral z avtomatiko ni pametno, pri nizjenivojskih konstruktih se pa ne izplaca.