Tråd styring

Den bedste maade at styre traade paa er at undgaa behovet for at styre traade.

:-)

Hvis det kan klare problemstillingen (hvilket det ofte men ikke altid kan) saa:
- lav thread pool med queue
- submit tasks til queue
- serielle tasks haandteres ved at et task som det sidste submitter naeste task
- al relevant kode skrives traadsikker saaledes at der kan kan kaldes metoder paa samme instans fra forskellige traade og resultat er garanteret korrekt

Har du en specifik problem-stilling i tankerne?

Ovenstaaende er "best case".

"Worst case" er lock, Wait og Pulse*.

Men der er en del muligheder midt imellem.

Jeg syntes bare nogle gange at man havner i en situation hvor det ender op i tråd problemer. f.eks. hvis et program anvender flere enheder sat til USB porten og kommunication mellem programmer.

Hvis der skal tilgaaes en ekstern resource som ikke kan bruges samtidigt, saa skal man synkronisere al adgang til denne. Typisk vil man nok bruge lock { } i de relevante metoder.

Med hensyn til kommunikation mellem processer, saa foretraekker jeg normalt en enkelt read traad og synkronisering af writes.

ok
Hvis vi lige tog et eksempel.

En DLL sender events til en klasse i et winforms program.
Disse events sørger for at vi får udført en række operationer i en switch/case skruktur.

switch(events)
{
case event1
Write/read fra Com port via dll
Opdater form/gui med de data der er hentet
break;
case event2
Hent data via en service
Opdater form/gui log
break;
case event3
Gem data i en database
Opdater form/gui log
break;
}

Hvordan ville denne skulle gribes an ?
Lave en backgroundworker der tog sig af det hele?

Det er svaert at designe en loesning med saa faa oplysninger.

Men lidt brainstorming:
* app main traad som ikke laver noget
* GUI event traad som er givet
* en reader traad til at laese events
* en threadpool
* reader thread sender tasks til threadpool
* tasks laver det de skal og opdaterer GUI via Invoke (som faar opdatering udfoert i event traad)
* klassen for COM port synkroniserer
* klassen for service interaction laves stateless
* klassen for database interaction laves stateless (hen ny connection, udfoer og luk igen)

Ja det er selvfølgelig svært, det var også bare et tænkt eksempel.
Det er en fin opdeling, havde jeg skulle lave det var min tanke nok kun på en tråd mere end gui, men jeg tror du har ret med at en bedre opdeling giver mere styr og bedre resultat.

Tak for dine svar det var meget givtigt