[C] X aantal threads maken en behouden

[Akerboom]

Ik ben met een programma bezig op mijn server in C. Het gaat om een RedHat Linux 9 server.

Daarin wil ik een programma maken die een lijst doorloopt en alles in die lijst met een extern programma uitvoert. Dit gedeelte heb ik al maar ik wil niet dat die lijst commando voor commando uitgevoerd wordt maar ik wil dat er bijvoorbeeld 50 threads actief zijn om de lijst te doorlopen.
Dus als een van die 50 client threads is afgelopen er een nieuwe thread gestart wordt met het volgende lijst element.

Waarmee is dit mogelijk? ik heb al aan spawnl() gedacht alleen dan kan ik maar op 1 thread wachten ik weet niet hoe ik er bv. 50 moet doen en daarnaast krijg ik spawnl() niet werkend onder linux.

[D2k]

kijk eens naar pthread_*

[.oisyn]

wat dacht je van fork () en exec ()

[Akerboom]

exec() geeft geen return status, dus weet ik niet of de client is afgelopen.
met fork() weet ik ook niet hoe ik dat 50x kan doen en dat aantal in evenwicht houden.

@D2K ik zal eens kijken naar pthread_*

[Akerboom]

ik dacht hiermee aan de gang te kunnen (hello.c):
http://www.llnl.gov/compu...s/pthreads/#CreateExample

Nu krijg ik alleen een compile error:

cc hello.c -o hello
/tmp/ccgCrdsZ.o(.text+0x6d): In function `main':
: undefined reference to `pthread_create'
collect2: ld gaf exit-status 1 terug
make: *** [hello] Fout 1

komt volgens mij omdat er wat bij de compile commando moet, ik weet niet wat... iemand?

[curry684]

Zoek je niet naar een threadpool implementatie omdat je wil voorkomen dat je constant de overhead kwijt bent van het maken van een nieuwe thread? (1 nieuwe thread maken ~= 30ms op een 500Mhz bak, recyclen ~= 0ms)

[.oisyn]

met pthread werken zal wel iets beter zijn, maar daar heb ik geen ervaring mee

fork () creeert een nieuw proces dat identiek is als het huidige. exec () start een nieuw proces over het huidige heen. Er is dus logischerwijs geen returnwaarde: jouw proces stopt gewoon bij de aanroep van exec.

Daarom doe je spawn () zoals dat in DOS/windows werkt in linux altijd met een combinatie van fork () en exec (). Fork retourneert in het parentproces de PID van de client. In het clientproces retourneert ie 0. En in het parent-proces kun je dan weer waiten op het exitten van de client

zoiets zeg maar:

C:

int main ()
{
    pid_t p;
    p = fork ();

    if (p == -1) // fork () is mislukt
        return 0;

    if (p == 0) // dit is de client
        exec ("executable hier"); // de code gaat niet verder dan exec ()

    wait (p); // p is de client pid, wacht op het sluiten van de client
}

Even uit mijn hoofd, er kunnen wat foutjes in zitten
Op deze manier kun je dus 50 clients spawnen, die op hun beurt weer steeds andere processen gaan spawnen en wachten tot ze klaar zijn

[IcE_364]

TormentoR schreef op 02 September 2003 @ 14:17:
ik dacht hiermee aan de gang te kunnen (hello.c):
http://www.llnl.gov/compu...s/pthreads/#CreateExample

Nu krijg ik alleen een compile error:
[...]


komt volgens mij omdat er wat bij de compile commando moet, ik weet niet wat... iemand?

Je moet nog -lpthread toevoegen

[curry684]

met pthread werken zal wel iets beter zijn, maar daar heb ik geen ervaring mee

Pthread = gewoon threads en werkt goed (ondanks bloedjelelijke API). Fork dupliceert het hele proces en is dus niet echt multithreading maar een lelijke vorm van multiprocessing. Spawn is tevens multiprocessing en vereist sourcefile scheiding (nieuwe executable).

[Akerboom]

.oisyn schreef op 02 September 2003 @ 14:22:

[knip]

Op deze manier kun je dus 50 clients spawnen, die op hun beurt weer steeds andere processen gaan spawnen en wachten tot ze klaar zijn

Maar dan ben ik de controle over de lijst kwijt, die zich in main bevindt.


@ IcE: ik gebruik nu als compile commando "cc hello.c -lpthread -D_POSIX_PTHREAD_SEMANTICS -o hello" gevonden op google toch bedankt!

Nu ik ptread_* aan de gang hebt moet het wel gaan lukken... loop ik weer vast dan post ik het hier wel... ondertussen.. alvast bedankt!

[.oisyn]

curry684 schreef op 02 September 2003 @ 14:27:
[...]

Pthread = gewoon threads en werkt goed (ondanks bloedjelelijke API). Fork dupliceert het hele proces en is dus niet echt multithreading maar een lelijke vorm van multiprocessing. Spawn is tevens multiprocessing en vereist sourcefile scheiding (nieuwe executable).

heb je daar geen kernel ondersteuning voor nodig trouwens? (en ja RH9 heeft dat wel, maar dat even terzijde )

TormentoR schreef op 02 September 2003 @ 14:29:
[...]


Maar dan ben ik de controle over de lijst kwijt, die zich in main bevindt.

shared memory

[D2k]

compilen met -lpthread

spuit elf -> [rml]IcE_364 in "[ C] X aantal threads maken en behouden"[/rml]

[ Voor 71% gewijzigd door curry684 op 02-09-2003 14:44 ]

[Verwijderd]

[laat]

.oisyn schreef op 02 september 2003 @ 14:31:
shared memory

Maar dan heb je toch geen fatsoenlijke locking? .

[.oisyn]

linux heeft toch wel locking mogelijkheden neem ik aan Zeker op shared memory lijkt me dat nuttig

Maar ik ben wat dat betreft meer een windowshippie, dus ik zou het niet weten

[curry684]

Shared memory kun je via global event flags synchronizeren, op VMS in ieder geval, en ik geloof dat Linux/Unix wat dat betreft hetzelfde werkt. Je kunt tevens (smartass mode) een mutex aanmaken via pthreads in het shared memory zelf, dus sizeof(pthread_mutex) extra reserveren en initializeren.

[Verwijderd]

curry684 schreef op 03 September 2003 @ 11:24:
Je kunt tevens (smartass mode) een mutex aanmaken via pthreads in het shared memory zelf, dus sizeof(pthread_mutex) extra reserveren en initializeren.

Lijkt me niet zo handig, want waarom gebruik je dan in hemelsnaam nog processes in plaats van threads? .

Global event flags ken ik niet, zal ik eens nazoeken. .

[.oisyn]

Als je threads gebruikt zul je je mem iig alsnog moeten synchronizen

[curry684]

Lijkt me niet zo handig, want waarom gebruik je dan in hemelsnaam nog processes in plaats van threads?

Er is voor zover ik kan zien geen enkele reden om dit in meer processen te doen, echter zoals oisyn al zegt: of je nu multiprocessed of multithread, synchronizeren moet je toch.