[C# /Mono] Thread synchronisatie problemen met GUI

Pagina: 1
Acties:
  • 103 views sinds 30-01-2008
  • Reageer

  • bimm
  • Registratie: November 2005
  • Laatst online: 08-03 22:16
Ik ben bezig om mijzelf aan te leren om in mijn programma's meer gebruik te maken van threading. Het is natuurlijk allemaal heel makkelijk zonder threads maar gebruik van threading geeft je programma net even dat mooie afgemaakte en professionele idee.

Nou, dat hebben mijn programma's dus niet want ik krijg allemaal synchronisatie problemen.

Het fijne is, dankzij de vele google topics hierover en de onoverzichtelijk tutorial gebruik ik netjes delegates en, in mijn form, the nodige invokerequired en invoke calls.

Leuk, maar, ik vind het een beetje naar of vreemd dat die events/callbacks van mij uberhaubt methods aanroepen uit de form die op een andere thread draaien. Het liefst namelijk wil ik, als ik mijn bibliotheek gebruik, transparant het threaden willen doen. Ik wil geen programmeur (ik) lastig vallen met achteraf nog eens overal invokerequired afvraagingen te doen. Ten tweede wil ik graag dat het ook nog eens platform onafhankelijk is. Dat wil zeggen, WinForms en Gtk#. Waar VC# gebruik maakt van InvokeRequired maakt GTK# gebruik van ThreadNotify.Wakeupmain. Dat is ongeveer wat ik ook wil in windows, alleen dan multi-platform. En geen gtk# onder windows.

Iemand een idee...? En iemand misschien een mooi, duidelijk en nederlands boek over C# threading?

Ik ook, jij niet?


  • rrrandy
  • Registratie: Juli 2005
  • Laatst online: 25-01 15:24
bimm schreef op woensdag 08 maart 2006 @ 13:59:
gebruik van threading geeft je programma net even dat mooie afgemaakte en professionele idee
Wanneer dit je motivatie is om threading te gaan gebruiken dan betwijfel ik of het ook echt nut heeft in de applicaties die je schrijft...

  • Gerco
  • Registratie: Mei 2000
  • Laatst online: 28-03 23:48

Gerco

Professional Newbie

rrrandy schreef op woensdag 08 maart 2006 @ 14:08:
Wanneer dit je motivatie is om threading te gaan gebruiken dan betwijfel ik of het ook echt nut heeft in de applicaties die je schrijft...
Je applicatie is al een stuk meer "af" wanneer de GUI thread los staat van 1 of meerdere "werk" threads. Dit zorgt ervoor dat je GUI altijd prompt reageert en zorgt weldegelijk voor een profi feel van de app. Apps waarbij de GUI thread blockt zijn vaak net iets minder prettig in het gebruik dan apps waarbij dat niet het geval is.

- "Als ik zou willen dat je het begreep, legde ik het wel beter uit!" | All number systems are base 10!


  • Sybr_E-N
  • Registratie: December 2001
  • Laatst online: 07-04 21:53
bimm schreef op woensdag 08 maart 2006 @ 13:59:
Iemand een idee...? En iemand misschien een mooi, duidelijk en nederlands boek over C# threading?
Heb je je zoiezo al eens verdiept in Threading in het algemeen? Ik krijg het gevoel dat je lang niet weet wat het nou allemaal inhoud en wanneer en hoe je het moet toepassen. Voor boeken, zie het [Alg] Centraal boekentopic - part II in SEA.

  • whoami
  • Registratie: December 2000
  • Laatst online: 07-04 22:26
Voor je eerste probleem: ik snap niet helemaal wat je bedoeld, kan je even wat relevante code tonen ?

https://fgheysels.github.io/


  • bimm
  • Registratie: November 2005
  • Laatst online: 08-03 22:16
Heb je je zoiezo al eens verdiept in Threading in het algemeen? Ik krijg het gevoel dat je lang niet weet wat het nou allemaal inhoud en wanneer en hoe je het moet toepassen. Voor boeken, zie het [Alg] Centraal boekentopic - part II in SEA.
Zoals Gerco zegt, mijn programma gebruikt inderdaad een aantal gedeeltelijk IO gebonden taken. Namelijk, hij zoekt automatisch door een aantal sites heen. En omdat ik niet wil dat mijn programma/GUI totaal hangt als hij bezig is met zoeken site per site maak ik gebruik van een Master class die voor elke zoekplugin een thread aanmaakt en deze daarin draait. GUI wordt netjes gedisabled terwijl hij bezig is maar blijft responsive.

Het probleem is echter als volgt: op het moment dat de threads klaar zijn roepen doen ze een lock op het Master object en activeren ze de Delegate event OnSearchCompleted. Deze is in gebruik door middel van de wel bekende += new OnSearchCompleted(MySearchCompleted) in the form. Echter, in deze MySearchCompleted moet ik altijd een InvokeRequired controle doen om deze thread te synchroniseren met de GUI thread. Lijkt op ThreadNotify.WakeupMain uit GTK#.

Echter, ik wil graag geen InvokeRequired hoeven controleren in mijn form. Ik weet niet of dit mogelijk is, maar deze controle wil ik verplaatsen naar de Master class.

Zinnige uitleg? Ik heb mijn voorbeeld niet bij de hand nu maar het is makkelijk te maken:

1) Nieuw windows form project.
2) Maak een nieuw .CS bestand aan met een tweetal klassen.
3) Eerste klasse Master die drie nep-zoekthreads starten.
4) Zorg ervoor dat een notificatie wordt gegeven aan de form waarin de GUI wordt geupdate met resultaten.

In dit voorbeeld, vermits je de gebruikelijke event delegate gebruikt, zal je ook InvokeRequired benodigd hebben, en dus threading aware code in the form. Alle thread relevante dingen wil ik in de .CS houden waar de Master class in zit en de zoek plugins.

Ik ook, jij niet?


  • TheNameless
  • Registratie: September 2001
  • Laatst online: 07-02-2025

TheNameless

Jazzballet is vet!

Ik heb geen ervaring in c# multi-threading, maar heb je al eens naar de volgende voorbeeld op MSDN gekeken: http://msdn.microsoft.com...edWindowsFormsControl.asp

Hier doen ze het volgens mij dus met BeginInvoke en zonder InvokeRequired

Ducati: making mechanics out of riders since 1946


  • bimm
  • Registratie: November 2005
  • Laatst online: 08-03 22:16
Ja, deze had ik gezien. En die heeft mij uiteindelijk gedreven dit te gaan typen.

Ik heb inderdaad al eerder thread programmeren gedaan, maar dan onder Delphi. En daar is het belachelijk makkelijk. Gewoon Synchronize() gebruiken en je zit op de GUI thread. Beetje alla ThreadNotify.WakeupMain() onder GTK#/mono. Niet hier dus.

En natuurlijk ook een beetje destijds vals gespeeld door multithreaded servers te bouwen....allemaal met Synchronize. Alleen, op een later tijdstip overgestapt naar het event based socket programming model van WinSock.

Is hier niet van toepassing trouwens.

Ik ook, jij niet?

Pagina: 1