---

Hej alle,

når man anvender fork() systemkaldet, så dannes en kopi af den kørende
proces.
Denne proces der så dannes, hvor eksekverer den fra?

Programmet anvender typisk noget a'la


pid_t pid;

if ((pid = fork()) > 0) {
printf("parent process");
}

if (pid == 0) {
printf("child executing");
}



spørgsmålet er så bare. fork() danner jo en kopi af det nu kørende
program, men kopien danner således ikke nogen ny kopi?
Hvordan laver en child-proces så en ny proces igen igen?



Med venlig hilsen
Preben Holm

---

Den Tue, 01 Jun 2004 22:28:50 +0200 skrev Preben:
> Hej alle,
>
> når man anvender fork() systemkaldet, så dannes en kopi af den kørende
> proces.
> Denne proces der så dannes, hvor eksekverer den fra?
>
> Programmet anvender typisk noget a'la
>
>
> pid_t pid;
>
> if ((pid = fork()) > 0) {
> printf("parent process");
> }
>
> if (pid == 0) {
> printf("child executing");
> }

Kopien er præcis samme sted i programmet som originalen, begge returnerer
fra fork(), men med forskellig retur-værdi.

fork returnerer nemlig 0 til child processen, og child'ens PID til
parent processen. Og et negativt tal hvis der er sket en fejl. Så hvis
ikke der var nogen if omkring fork, ville begge processer opføre sig
ens.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

>>pid_t pid;
>>
>>if ((pid = fork()) > 0) {
>> printf("parent process");
>>}
>>
>>if (pid == 0) {
>> printf("child executing");
>>}
>
>
> Kopien er præcis samme sted i programmet som originalen, begge returnerer
> fra fork(), men med forskellig retur-værdi.
>
> fork returnerer nemlig 0 til child processen, og child'ens PID til
> parent processen. Og et negativt tal hvis der er sket en fejl. Så hvis
> ikke der var nogen if omkring fork, ville begge processer opføre sig
> ens.

Ahh, smart.. Nu forstår jeg

Når man nu tænker på alt det der smart med copy-on-write osv. som der er
implementeret i linux, hvordan med allokering af hukommelse til nyt program.
Hvis man nu vælger at loade et andet program efter at have "fork"'et ved
straks at kalde en exec() (eller familie heraf) systemkald. Hvordan
allokeres hukommelsen så egentlig!
Hvordan rådes der over hukommelsen? Har terminalen rådighed over næsten
al hukommelse og kan derfor give ud af sin "egen" hukommelse til det
loadede program eller allokeres der hukommelse vha. selve
operativsystemkaldet exec***()?

Hvad er POSIX tråde egentlig?


Mvh / Preben Holm

---

Den Wed, 02 Jun 2004 19:26:15 +0200 skrev Preben:
>
> Når man nu tænker på alt det der smart med copy-on-write osv. som der er
> implementeret i linux, hvordan med allokering af hukommelse til nyt program.

Der bliver ikke allokeret noget før der er brug for det. Lige efter en
fork() er begge processer read-only, og når en af dem så forsøger at
skrive til en adresse, bliver den page (typisk 4 kilobyte) kopieret.

> Hvis man nu vælger at loade et andet program efter at have "fork"'et ved
> straks at kalde en exec() (eller familie heraf) systemkald. Hvordan
> allokeres hukommelsen så egentlig!

Det nye program loades "on demand" fra disk, efterhånden som der bliver
brug for det.

> Hvordan rådes der over hukommelsen? Har terminalen rådighed over næsten
> al hukommelse og kan derfor give ud af sin "egen" hukommelse til det
> loadede program eller allokeres der hukommelse vha. selve
> operativsystemkaldet exec***()?

Kernen råder over al hukommelsen, og deler ud til de programmer der
skal bruge noget, vha fork copy-on-write, exec, brk (malloc), mmap
(memory-map'ede filer) osv.

> Hvad er POSIX tråde egentlig?

Set fra en alm. programmørs synspunkt minder de om processer, bortset
fra at de deler hukommelsen (undtagen stakken), og der ikke er noget
der forhindrer at de overskriver hinandens data.

Set fra systemets synspunkt kan de virke på flere måder, enten som ren
userspace, altså et library der laver al arbejdet, og systemet kun ser
en process, eller som separate process-id'er, der bare deler alting,
eller en kombination.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

>>Hvis man nu vælger at loade et andet program efter at have "fork"'et ved
>>straks at kalde en exec() (eller familie heraf) systemkald. Hvordan
>>allokeres hukommelsen så egentlig!
>
>
> Det nye program loades "on demand" fra disk, efterhånden som der bliver
> brug for det.

Ja ok, men jeg tænker mere på data og stack end _TEXT segmentet!


>>Hvad er POSIX tråde egentlig?
>
>
> Set fra en alm. programmørs synspunkt minder de om processer, bortset
> fra at de deler hukommelsen (undtagen stakken), og der ikke er noget
> der forhindrer at de overskriver hinandens data.
>
> Set fra systemets synspunkt kan de virke på flere måder, enten som ren
> userspace, altså et library der laver al arbejdet, og systemet kun ser
> en process, eller som separate process-id'er, der bare deler alting,
> eller en kombination.

Sorry, glemte lige at skrive det helt præcist:
Hvad er POSIX tråde i forhold til alm. kernel-tråde implementeret vha.
fork()?
Hvor kan jeg læse mere om POSIX? Så vidt jeg har forstået er det et fast
defineret standard interface mod kernen om hvordan API snitfladen er lavet.
Hvor findes en oversigt over denne snitflade og hvor præcist er det
defineret?


Mvh / Preben Holm

---

Den Wed, 02 Jun 2004 20:08:33 +0200 skrev Preben:
>>>Hvis man nu vælger at loade et andet program efter at have "fork"'et ved
>>>straks at kalde en exec() (eller familie heraf) systemkald. Hvordan
>>>allokeres hukommelsen så egentlig!
>>
>>
>> Det nye program loades "on demand" fra disk, efterhånden som der bliver
>> brug for det.
>
> Ja ok, men jeg tænker mere på data og stack end _TEXT segmentet!

Stack er under alle omstændigheder separat efter fork(), også inden
exec(). Men exec() må nødvendigvis nulstille både heap og stack, for
de gamle data giver ingen mening for det nye program.

>>>Hvad er POSIX tråde egentlig?
>>
>> Set fra en alm. programmørs synspunkt minder de om processer, bortset
>> fra at de deler hukommelsen (undtagen stakken), og der ikke er noget
>> der forhindrer at de overskriver hinandens data.
>>
>> Set fra systemets synspunkt kan de virke på flere måder, enten som ren
>> userspace, altså et library der laver al arbejdet, og systemet kun ser
>> en process, eller som separate process-id'er, der bare deler alting,
>> eller en kombination.
>
> Sorry, glemte lige at skrive det helt præcist:
> Hvad er POSIX tråde i forhold til alm. kernel-tråde implementeret vha.
> fork()?

Kernel-tråde er ikke implenteret vha fork, det er tråde der kører som
en del af kernen, og som kernen selv starter op.

> Hvor kan jeg læse mere om POSIX? Så vidt jeg har forstået er det et fast
> defineret standard interface mod kernen om hvordan API snitfladen er lavet.
> Hvor findes en oversigt over denne snitflade og hvor præcist er det
> defineret?

Jeg vil gætte på ISO eller lignende.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Preben wrote:
>
> >>Hvis man nu vælger at loade et andet program efter at have "fork"'et ved
> >>straks at kalde en exec() (eller familie heraf) systemkald. Hvordan
> >>allokeres hukommelsen så egentlig!
> >
> >
> > Det nye program loades "on demand" fra disk, efterhånden som der bliver
> > brug for det.
>
> Ja ok, men jeg tænker mere på data og stack end _TEXT segmentet!

Typisk vil pladsen vel først alloceres når data skal
kopieres ved CoW. Man kan evt. udregne på forhånd hvor
meget man i værste fald kan få brug for, og lade fork()
returnere en fejl, hvis man ikke er sikker på at have
plads nok. Men selvom man regner ud hvor meget man kan
få brug for er der ingen grund til at allocere den
fysiske hukommelse før man reelt har brug for den.
Indtil da kan den så bruges på andre processer eller
cache.

>
> Sorry, glemte lige at skrive det helt præcist:
> Hvad er POSIX tråde i forhold til alm. kernel-tråde implementeret vha.
> fork()?

fork() laver ikke tråde. fork() laver processer. Hvad
der så lige vil ske hvis man først laver et antal tråde,
og derefter kalder fork(), er jeg ikke klar over. Det
ville give glimrende mening hvis et multitrådet program
gerne ville starte en ny process og så kalde en af exec
funktionerne. Men hvordan sikrer man sig et forudsigeligt
udfald uanset om tråde er implementeret i kernen eller i
et library.

> Hvor kan jeg læse mere om POSIX? Så vidt jeg har forstået er det et fast
> defineret standard interface mod kernen om hvordan API snitfladen er lavet.
> Hvor findes en oversigt over denne snitflade og hvor præcist er det
> defineret?

Jeg tror nok at POSIX standarden er en man skal betale
for at få et eksemplar af. Men du kan tage et kig på The
Single UNIX Specification http://www.unix-systems.org/

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk
I'd rather be a hammer than a nail.

---

>>>Hvad er POSIX tråde egentlig?
>>
>> Set fra en alm. programmørs synspunkt minder de om processer, bortset
>> fra at de deler hukommelsen (undtagen stakken), og der ikke er noget
>> der forhindrer at de overskriver hinandens data.
>>
>> Set fra systemets synspunkt kan de virke på flere måder, enten som ren
>> userspace, altså et library der laver al arbejdet, og systemet kun ser
>> en process, eller som separate process-id'er, der bare deler alting,
>> eller en kombination.
>
> Sorry, glemte lige at skrive det helt præcist:
> Hvad er POSIX tråde i forhold til alm. kernel-tråde implementeret vha.
> fork()?

Nej, kig på clone(2). clone() er et systemkald der minder om fork, men hvor
et variabelt udsnit af den gamle proces deles med den nye.

--
M.V.H
Christian Iversen

---

Christian Iversen wrote:
>
> Nej, kig på clone(2). clone() er et systemkald der minder om fork, men hvor
> et variabelt udsnit af den gamle proces deles med den nye.

Inden man begynder at bruge clone skal man lige være
opmærksom på, at det er et kald, der kun findes på Linux.
Hvis man vil lave portable programmer er posix tråde et
bedre valg. (På Linux må de så være implementeret vha.
clone).

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk
I'd rather be a hammer than a nail.

---

Kasper Dupont wrote:
> Christian Iversen wrote:
>
>>Nej, kig på clone(2). clone() er et systemkald der minder om fork, men hvor
>>et variabelt udsnit af den gamle proces deles med den nye.
>
>
> Inden man begynder at bruge clone skal man lige være
> opmærksom på, at det er et kald, der kun findes på Linux.
> Hvis man vil lave portable programmer er posix tråde et
> bedre valg. (På Linux må de så være implementeret vha.
> clone).

Giver fork ikke mulighed for at specificere hvilke dele der skal være delt.

Iøvrigt skelner Linux ikke mellem tråde og processer!
Det er korrekt at f.eks. solaris gør det!
Hvor vidt UNIX generelt gør det, tør jeg desværre ikke udtale mig om!

---

Den Thu, 03 Jun 2004 17:37:29 +0200 skrev Preben:
> Kasper Dupont wrote:
>> Christian Iversen wrote:
>>
>>>Nej, kig på clone(2). clone() er et systemkald der minder om fork, men hvor
>>>et variabelt udsnit af den gamle proces deles med den nye.
>>
>>
>> Inden man begynder at bruge clone skal man lige være
>> opmærksom på, at det er et kald, der kun findes på Linux.
>> Hvis man vil lave portable programmer er posix tråde et
>> bedre valg. (På Linux må de så være implementeret vha.
>> clone).
>
> Giver fork ikke mulighed for at specificere hvilke dele der skal være delt.

SYNOPSIS
#include <unistd.h>

pid_t fork(void);

fork() giver ikke mulighed for at specificere noget som helst.

> Iøvrigt skelner Linux ikke mellem tråde og processer!

Den holder vist ikke længere i 2.6, jfr. PID vs TID vs TGID.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

>>Giver fork ikke mulighed for at specificere hvilke dele der skal være delt.
>
>
> SYNOPSIS
> #include <unistd.h>
>
> pid_t fork(void);
>
> fork() giver ikke mulighed for at specificere noget som helst.
>
>
>>Iøvrigt skelner Linux ikke mellem tråde og processer!
>
>
> Den holder vist ikke længere i 2.6, jfr. PID vs TID vs TGID.

Hmm.. mærkeligt at Robert Love skriver det i sin bog som omhandler
2.5/2.6 kerneudvikling

---

Kasper Dupont wrote:

> Christian Iversen wrote:
>>
>> Nej, kig på clone(2). clone() er et systemkald der minder om fork, men
>> hvor et variabelt udsnit af den gamle proces deles med den nye.
>
> Inden man begynder at bruge clone skal man lige være
> opmærksom på, at det er et kald, der kun findes på Linux.
> Hvis man vil lave portable programmer er posix tråde et
> bedre valg. (På Linux må de så være implementeret vha.
> clone).

Jeg mente blot at han skulle kigge på det, for at få en idé om hvordan tråde
er implementeret på linux. Det var det spørgsmålet gik på :)

--
M.V.H
Christian Iversen

---

Kent Friis wrote:
>
> Set fra en alm. programmørs synspunkt minder de om processer, bortset
> fra at de deler hukommelsen (undtagen stakken), og der ikke er noget
> der forhindrer at de overskriver hinandens data.

De deler faktisk hele deres hukommelse inklusiv stakkene.
Men i det delte adresserum er der allokeret et stak område
til hver tråd, hver tråd har sit eget registerindhold
inklusiv stakpointer, derfor kan trådene bruge hver sin
stak. Men intet forhindre trådene i at læse og skrive
hinandens stakke.

Man er stort set nødt til at gøre det på den måde, ellers
ville man miste de performance fordele, der er ved tråde.

>
> Set fra systemets synspunkt kan de virke på flere måder, enten som ren
> userspace, altså et library der laver al arbejdet, og systemet kun ser
> en process, eller som separate process-id'er, der bare deler alting,
> eller en kombination.

En ren library implementation vil give problemer omkring
blokerende systemkald, og vil ikke kunne udnytte multicpu
maskiner. Så det er typisk en dårlig idé.

En ren kerne implementation kan fungere meget godt.

En kombination kan nemt gå hen at blive meget kompliceret.
I nogle få situationer kan en kombiløsning give bedre
performance end en ren kerne implementation. Men jeg
tvivler på at fordelene kan opveje ulemperne.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk
I'd rather be a hammer than a nail.

---

Den Wed, 02 Jun 2004 20:13:03 +0200 skrev Kasper Dupont:
> Kent Friis wrote:
>>
>> Set fra en alm. programmørs synspunkt minder de om processer, bortset
>> fra at de deler hukommelsen (undtagen stakken), og der ikke er noget
>> der forhindrer at de overskriver hinandens data.
>
> De deler faktisk hele deres hukommelse inklusiv stakkene.
> Men i det delte adresserum er der allokeret et stak område
> til hver tråd, hver tråd har sit eget registerindhold
> inklusiv stakpointer, derfor kan trådene bruge hver sin
> stak. Men intet forhindre trådene i at læse og skrive
> hinandens stakke.

Det modsiger reelt heller ikke det jeg skriver, det er bare en mere
præcis formulering.

>> Set fra systemets synspunkt kan de virke på flere måder, enten som ren
>> userspace, altså et library der laver al arbejdet, og systemet kun ser
>> en process, eller som separate process-id'er, der bare deler alting,
>> eller en kombination.
>
> En ren library implementation vil give problemer omkring
> blokerende systemkald, og vil ikke kunne udnytte multicpu
> maskiner. Så det er typisk en dårlig idé.

Mig bekendt virker pthreads på den måde (?)

> En ren kerne implementation kan fungere meget godt.
>
> En kombination kan nemt gå hen at blive meget kompliceret.
> I nogle få situationer kan en kombiløsning give bedre
> performance end en ren kerne implementation. Men jeg
> tvivler på at fordelene kan opveje ulemperne.

Så vidt jeg husker diskuterede man det netop på LKML, fordi alle havde
den opfattelse at en kombination er "det eneste der duer(tm)". Indtil
folk så resultatet af den nye implementation i 2.6.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis wrote:
>
> Den Wed, 02 Jun 2004 20:13:03 +0200 skrev Kasper Dupont:
> >
> > En ren library implementation vil give problemer omkring
> > blokerende systemkald, og vil ikke kunne udnytte multicpu
> > maskiner. Så det er typisk en dårlig idé.
>
> Mig bekendt virker pthreads på den måde (?)

Er det korrekt forstået at pthreads og Posix Threads er
det samme? Eller er det sådan at pthreads er en konkret
implementation af Posix Threads?

Så vidt jeg har forstået er standarden udformet sådan,
at en ren library implementation mere eller mindre
automatisk vil overholde standarden.

Men det forhindrer ikke at man også kan lave en kerne
implementation der også overholder standarden.

>
> > En ren kerne implementation kan fungere meget godt.
> >
> > En kombination kan nemt gå hen at blive meget kompliceret.
> > I nogle få situationer kan en kombiløsning give bedre
> > performance end en ren kerne implementation. Men jeg
> > tvivler på at fordelene kan opveje ulemperne.
>
> Så vidt jeg husker diskuterede man det netop på LKML, fordi alle havde
> den opfattelse at en kombination er "det eneste der duer(tm)". Indtil
> folk så resultatet af den nye implementation i 2.6.

Men Linux har længe haft en ren kerne implementation
af tråde. Den har bare ikke hidtil overholdt Posix.
(Der var vist noget med at Linus syntes Posix standarden
var tåbelig). Ændringerne er så vidt jeg har forstået
drejet sig omkring pid og signaler.

Hidtil har hver tråd fået et seperat process id. Men med
Posix skal de have det samme. Det er så blevet løst ved
at man stadig tildeler pid som man hidtil har gjort, men
i stedet for at kalde det for et pid, så kaldes det nu
for et thread id. Og så er getpid blevet ændret så den
altid returnerer pid på den første tråd, også kaldet for
thread group id.

Og så er der noget med signaler. F.eks. mener jeg at et
ikke håndteret signal skal dræbe alle tråde, hvor det
tidligere kun dræbte den ene det blev sendt til. Det er
oplagt fordi det ene svarer til, hvordan det vil virke
i en library implementation, mens det andet er det
nemmeste i en kerne implementation.

Jeg har aldrig helt forstået hvorfor nogen var så vilde
med kombiløsningerne. Jeg tror nok det var ud fra en
tankegang om, at kernen kan ikke håndtere så mange tråde,
så vi må hellere nøjes med nogle få tråde og så lave en
user mode implementation ovenpå det. Men en kerne kan
sagtens implementeres, så den håndterer *mange* tråde på
fornuftig vis. Det nye i Linux 2.6 er vist, at der er
nogen, der har taget sig sammen og gjort det.

Den eneste fordel jeg kan få øje på ved kombiløsningen
fremfor en ren kerne løsning er, at frivillige trådskift
kan udføres uden overheadet til et skift mellem user og
kernel mode. Men jeg ville nu stadig lade kernen se lige
så mange tråde, som programmet opretter. Og så blot lave
noget "magi" i library koden, som kan bytte om på den
kørende tråd og en anden tråd, der ligger klar i run køen.

Jeg har dog aldrig hørt om nogen, der har prøvet på at
lave lige netop det nummer, jeg beskriver. Måske er det
et nummer for langhåret.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk
I'd rather be a hammer than a nail.

---

Den Wed, 02 Jun 2004 20:54:19 +0200 skrev Kasper Dupont:
> Kent Friis wrote:
>>
>> Den Wed, 02 Jun 2004 20:13:03 +0200 skrev Kasper Dupont:
>> >
>> > En ren library implementation vil give problemer omkring
>> > blokerende systemkald, og vil ikke kunne udnytte multicpu
>> > maskiner. Så det er typisk en dårlig idé.
>>
>> Mig bekendt virker pthreads på den måde (?)
>
> Er det korrekt forstået at pthreads og Posix Threads er
> det samme? Eller er det sådan at pthreads er en konkret
> implementation af Posix Threads?

pthreads er libpthreads, så det må være en konkret implementation.

> Så vidt jeg har forstået er standarden udformet sådan,
> at en ren library implementation mere eller mindre
> automatisk vil overholde standarden.
>
> Men det forhindrer ikke at man også kan lave en kerne
> implementation der også overholder standarden.

Naturligvis ikke.

>> > En ren kerne implementation kan fungere meget godt.
>> >
>> > En kombination kan nemt gå hen at blive meget kompliceret.
>> > I nogle få situationer kan en kombiløsning give bedre
>> > performance end en ren kerne implementation. Men jeg
>> > tvivler på at fordelene kan opveje ulemperne.
>>
>> Så vidt jeg husker diskuterede man det netop på LKML, fordi alle havde
>> den opfattelse at en kombination er "det eneste der duer(tm)". Indtil
>> folk så resultatet af den nye implementation i 2.6.
>
> Men Linux har længe haft en ren kerne implementation
> af tråde. Den har bare ikke hidtil overholdt Posix.
> (Der var vist noget med at Linus syntes Posix standarden
> var tåbelig). Ændringerne er så vidt jeg har forstået
> drejet sig omkring pid og signaler.

Ikke kun, der var en større omskrivning, der gør at Linux nu kan
håndtere rigtig mange tråde, og starte og stoppe dem lynhurtigt.

De andre ting du nævner har også været diskuteret.

> Jeg har aldrig helt forstået hvorfor nogen var så vilde
> med kombiløsningerne. Jeg tror nok det var ud fra en
> tankegang om, at kernen kan ikke håndtere så mange tråde,
> så vi må hellere nøjes med nogle få tråde og så lave en
> user mode implementation ovenpå det.

Det forekommer mig at "alle andre" (FreeBSD, Solaris osv) skulle
bruge kombinationsløsningen.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis wrote:
>
> Den Wed, 02 Jun 2004 20:54:19 +0200 skrev Kasper Dupont:
> > Kent Friis wrote:
> >>
> >> Så vidt jeg husker diskuterede man det netop på LKML, fordi alle havde
> >> den opfattelse at en kombination er "det eneste der duer(tm)". Indtil
> >> folk så resultatet af den nye implementation i 2.6.
> >
> > Men Linux har længe haft en ren kerne implementation
> > af tråde. Den har bare ikke hidtil overholdt Posix.
> > (Der var vist noget med at Linus syntes Posix standarden
> > var tåbelig). Ændringerne er så vidt jeg har forstået
> > drejet sig omkring pid og signaler.
>
> Ikke kun, der var en større omskrivning, der gør at Linux nu kan
> håndtere rigtig mange tråde, og starte og stoppe dem lynhurtigt.

Jeg nævnte kun de ændringer, der havde noget med overholdelse
af standarden at gøre. Jeg er godt klar over, at der er blevet
lavet mange andre ændringer med henblik på at forbedre
performance (ikke fordi tråde i Linux tidligere var dårlige i
sammenligning med andre systemer).

>
> Det forekommer mig at "alle andre" (FreeBSD, Solaris osv) skulle
> bruge kombinationsløsningen.

Men opnår de alle fordele fra hhv. kerne og user mode
implementationer? Eller er det bare et spørgsmål om, at
kernen ikke skal have så mange tråde at se på?

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk
I'd rather be a hammer than a nail.

---

Kasper Dupont wrote:
> En ren library implementation vil give problemer omkring
> blokerende systemkald, og vil ikke kunne udnytte multicpu
> maskiner. Så det er typisk en dårlig idé.

pthreads fungerer mig bekendt som en ren library-loesning.

> En ren kerne implementation kan fungere meget godt.

Problemet er blot, at du saa skal kaempe med langsomme mode-switches. Du
skal lave eet switch tilbage i kernel space for at skifte traad, og et
nyt for at skifte tilbage til naeste traad i koeen.

> En kombination kan nemt gå hen at blive meget kompliceret.
> I nogle få situationer kan en kombiløsning give bedre
> performance end en ren kerne implementation. Men jeg
> tvivler på at fordelene kan opveje ulemperne.

Sun bruger da en kombiloesning i Solaris, mener jeg. Det er maaske
kompliceret, men det virker godt.

Mvh. Michael.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

>> En ren library implementation vil give problemer omkring
>> blokerende systemkald, og vil ikke kunne udnytte multicpu
>> maskiner. Så det er typisk en dårlig idé.
>
>
> pthreads fungerer mig bekendt som en ren library-loesning.
>
>> En ren kerne implementation kan fungere meget godt.
>
>
> Problemet er blot, at du saa skal kaempe med langsomme mode-switches. Du
> skal lave eet switch tilbage i kernel space for at skifte traad, og et
> nyt for at skifte tilbage til naeste traad i koeen.
>
>> En kombination kan nemt gå hen at blive meget kompliceret.
>> I nogle få situationer kan en kombiløsning give bedre
>> performance end en ren kerne implementation. Men jeg
>> tvivler på at fordelene kan opveje ulemperne.
>
>
> Sun bruger da en kombiloesning i Solaris, mener jeg. Det er maaske
> kompliceret, men det virker godt.


Så vidt jeg ved tilbyder sun bare kerne-tråde, hvor hver LWP (light
weight process) kan vælge at schedulere mellem sine tilknyttede
user-level tråde. Ved at lade to LWP'er skifte mellem de samme tråde kan
man på den måde opnå en kombination.
Men hvor vidt kernen involveres i LWP'ernes userlevel tråde tror jeg
ikke man skal gætte yderligere på.
Jeg tror, at de vha. lidt IPC kan kommunikere og fortælle hinanden
hvilken tråd de skal til at starte, således den "delende" LWP ikke
vælger den samme tråd som lige er ved at blive behandlet (og måske har
forårsaget en blokering af LWP'en).
Jeg kan ikke se ideen med at kernen skal kende til user-level trådene
(så er ideen med en user-level tråd vel væk idet det bliver kernen der
alligevel skal administrere denne).

En solaris expert kunne jo lige fortælle om hvorvidt min "teori" er
rigtig eller forkert!

Mvh / Preben Holm

---

Preben wrote:
>> Sun bruger da en kombiloesning i Solaris, mener jeg. Det er maaske
>> kompliceret, men det virker godt.
>
>
>
> Så vidt jeg ved tilbyder sun bare kerne-tråde, hvor hver LWP (light
> weight process) kan vælge at schedulere mellem sine tilknyttede
> user-level tråde. Ved at lade to LWP'er skifte mellem de samme tråde
> kan man på den måde opnå en kombination. Men hvor vidt kernen
> involveres i LWP'ernes userlevel tråde tror jeg ikke man skal gætte
> yderligere på. Jeg tror, at de vha. lidt IPC kan kommunikere og
> fortælle hinanden hvilken tråd de skal til at starte, således den
> "delende" LWP ikke vælger den samme tråd som lige er ved at blive
> behandlet (og måske har forårsaget en blokering af LWP'en). Jeg kan
> ikke se ideen med at kernen skal kende til user-level trådene (så er
> ideen med en user-level tråd vel væk idet det bliver kernen der
> alligevel skal administrere denne).

Idéen er, at du kan lade flere userland-traade koere samtidig paa hver
sin CPU (via LWT), samt at det bliver muligt for dig at lave IO i traade.

> En solaris expert kunne jo lige fortælle om hvorvidt min "teori" er
> rigtig eller forkert!

Nu er jeg ikke ekspert, men jeg mindes, at dette er formaalet (eet af
dem) med at goere det paa denne maade. Jeg vil laese op paa det, naar
jeg kommer hjem, og saa vender jeg tilbage, hvis jeg har taget fejl.

Mvh. Michael.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

Preben <64bitNOnoNOSPAM@mailme.dk> writes:

> Hvordan laver en child-proces så en ny proces igen igen?

Den kalder bare fork() igen igen

--
Jacob - www.bunk.cc
Who was that masked man?