[Kylix] Multi threaded applicatie

[Verwijderd]

Ik ben bezig om een multi threaded applicatie te maken. Ik heb 1 pc waarop ik een applicatie draai. Het gaat in dit geval om een bowling score systeem. Dus 1 applicatie zorgt voor 4 onafhankelijk van elkaar werkende score schermen.

Nu ben ik van plan om het als volgt te gaan maken.

Ik heb 1 form wat het main form is. Hierop plaats ik een TLaneComputer. Dit object creeert een aantal TBowlingLane instanties.

Die TBowlingLane objecten zijn gebaseerd op Threads. Deze TBowlingLane instanties kan je dus zien als aparte programma's die draaien op de monitoren boven de banen.

Echter bij de volgende test werkt het niet echt lekker:

Op mijn main form heb ik een knop waar ik een TBowlingLane instantie aanmaak.

Delphi:

BowlingLane1 := TBowlingLane.Create(False);

C:

unit BowlingLane;

interface

uses
  SysUtils, Types, Classes, Variants, QTypes, QGraphics, QControls, QForms,
  QDialogs, QStdCtrls, WelcomeScreen, SyncObjs;

type
  TBowlingLane = class(TThread)
  private
    { Private declarations }
    WelcScreen: Tfrm_WelcomeScreen;
  protected
    { Protected declarations }
    procedure Execute; override;
  public
    { Public declarations }
  published
    { Published declarations }
  end;

implementation

{ TBowlingLane }

procedure TBowlingLane.Execute;
begin
  WelcScreen := Tfrm_WelcomeScreen.Create(nil);
  WelcScreen.Show;

  repeat

  until Application.Terminated;
end;

end.

WelcomeScreen is een formulier waarop een timer staat:

C:

procedure Tfrm_WelcomeScreen.Timer1Timer(Sender: TObject);
begin
  Timer1.Enabled := False;
  if lbl_Vuurknop.Visible then
    lbl_Vuurknop.Visible := False
  else
    lbl_Vuurknop.Visible := True;
  Timer1.Enabled := True;
end;

Als ik dit project uitvoer, dan loopt het steeds vast, of het welcomescreen wordt niet eens getoond, enz..

Er is niet echt een duidelijke indicatie wat het kan zijn.

Maar is er misschien iets dat ik helemaal verkeerd doe in het ontwerp?

[Creepy]

En m.b.v. F7 door je applicatie heen stappen geeft ook geen extra info?

[OxiMoron]

Hmm.. studeer jij toevallig Informatica aan het NHL?

anyway..

m'n delphi is een beetje roestig..

maar je moet de create van je form zo ie zo afvangen.

volgens mij deed je dat zo:

code:

With Tfrm_WelcomeScreen.Create(nil) do
Try:
    Showmodal;
Finally:
    Free;
end;

Dat ie zo ie zo wat netter..
of het werkt weet ik zo niet

[Verwijderd]

Creepy schreef op 10 maart 2003 @ 15:31:
En m.b.v. F7 door je applicatie heen stappen geeft ook geen extra info?

Nee, want dan blijft het programma bijvoorbeeld hangen net na het aanmaken van het TBowlingLane object.

[Creepy]

Verwijderd schreef op 10 maart 2003 @ 16:02:
[...]
Nee, want dan blijft het programma bijvoorbeeld hangen net na het aanmaken van het TBowlingLane object.

dus het hang na de create? Meteen? Dat is wel heel erg vreemd als je een tthread instantieert met false als parameter. Je vangt niet de create af in je thread object (zo te zien niet, tenzij je niet alle code hebt gepost)?

Hmm.. bovenstaande is dus onzin.. Ik haalde de werking van de parameter ff door de war. als je dat ding met false create gaat ie meteen runnen... zie ook Curry

[ Voor 17% gewijzigd door Creepy op 10-03-2003 16:11 ]

[curry684]

Goh op de NHL hebben ze vast en zeker Win95/98 en ME machines om op te developen, dat is namelijk het enige type OS waarop je dit soort fantastische thread starvation (zoek eens op wat het betekent) kunt reproduceren.

Op het moment dat je die term hebt opgezocht en de functie Sleep ook even hebt doorgenomen kunnen we verder babbelen over het slechte design.

[ Voor 5% gewijzigd door curry684 op 10-03-2003 16:08 . Reden: REACT IS KUT ]

[Verwijderd]

curry684 schreef op 10 March 2003 @ 16:08:Goh op de NHL hebben ze vast en zeker Win95/98 en ME machines om op te developen, dat is namelijk het enige type OS waarop je dit soort fantastische thread starvation (zoek eens op wat het betekent) kunt reproduceren.

Ik zit niet op het NHL, maar op de HR (Hogeschool Rotterdam). Maar momenteel ben ik aan het afstuderen bij een bedrijf en ontwikkel hier met kylix op een SuSE 8 machine.

[curry684]

Verwijderd schreef op 10 March 2003 @ 16:15:
[...]
Ik zit niet op het NHL, maar op de HR (Hogeschool Rotterdam). Maar momenteel ben ik aan het afstuderen bij een bedrijf en ontwikkel hier met kylix op een SuSE 8 machine.

Op een Linux-bak zouden de symptomen die je noemt in principe net zomin als op een NT/2k/XP-bak ernstig op mogen treden. Ik denk dat je niet echt lang gewacht hebt op het resultaat, na 5 minuten had je vast en zeker wat moeten zien

Iig de essentie is hetzelfde, zoek die 2 dingen die ik aangaf maar op.

[LordLarry]

Tis een beetje omgekeerde wereld wat je hier doet. Waarom niet gewoon 4 forms of zelfs 4x je applicatie starten? Je forms trekken zich niets aan van de threads en het geeft dus geen voordeel. Threads zijn alleen nuttig voor langdurige taken (berekeningen) die gedaan moeten worden terwijl de GUI gewoon moet blijven werken. Om je nog meer tips te geven na curry684: Kijk eens naar de CPU load (processor belasting) als je die thread gestart hebt...

/edit
vanwege de event driven architectuur van de GUI is het niet nodig threads te gebruiken om meerdere forms tegelijk naastelkaar in hetzelfde process te laten draaien. Multithreading wordt hiermee gesimuleerd voor de gebruiker.

[ Voor 21% gewijzigd door LordLarry op 10-03-2003 19:44 ]

[martijn_brinkers]

VCL is niet multi-thread safe dwz je mag alleen VCL dingen doen met de main thread als je niet zeker weet dat het multi-thread safe is. Vooral GUI dingen, zoals forms, zijn NIET thread safe en dus het aanmaken van een form en show in een thread zoals jij doet werkt niet. Je kan synchronize (of zelf via messages) gebruiken om een thread te synchronizeren met de main thread

[Verwijderd]

Bedankt voor alle reacties.

Ik zit inderdaad veel te moeilijk te denken. Ik moet het ontwerp aanpassen en niet d.m.v. de threads formulieren aanmaken.

[LordLarry]

TijnFLiP schreef op 10 maart 2003 @ 20:16:
VCL is niet multi-thread safe dwz je mag alleen VCL dingen doen met de main thread als je niet zeker weet dat het multi-thread safe is. Vooral GUI dingen, zoals forms, zijn NIET thread safe en dus het aanmaken van een form en show in een thread zoals jij doet werkt niet. Je kan synchronize (of zelf via messages) gebruiken om een thread te synchronizeren met de main thread

Een form creeeren in een thread mag best hoor. Vooral omdat forms bijna alleen via messages werken. Problemen met threads ontstaan alleen als je hetzelfde stuk geheugen gaat benaderen door meerdere threads tegelijk. Dit is (nog) niet het geval bij het voorbeeld van de TS. Maar je hebt wel gelijk dat dit gevaar bestaat.

[ Voor 5% gewijzigd door LordLarry op 10-03-2003 20:47 ]

[martijn_brinkers]

Je hebt gelijk. Net gezien dat het creeren thread-safe is. Echter zou ik het sterk afraden ervan uit te gaan dat iets thread-safe is als je dat niet zeker weet. In het geval van Form creation is dat het geval omdat ze de constructor hebben 'beveiligd' met een TMultiReadExclusiveWriteSynchronizer. Echter toch ondersteund VCL geen forms in meerdere threads zie bijv (is wel BCB maar is ook VCL)

http://tinyurl.com/77nd

Waar de knelpunten allemaal precies zitten weet ik niet (zal ook niet eenvoudig zijn op te lossen) maar bijv in Controls.pas is een globale var

CaptureControl: TControl = nil;

die op meerder punten gebruikt wordt en zeker in de messageloop. Dit zal zeker problemen kunnen geven wanneer je meerdere threads hebt die iets met forms doen. Er zullen zeker nog heel veel andere probleemgevallen zijn. Nou ja moraal van het verhaal.... als je niet zeker weet dat het multi-thread-safe is ga er dan vanuit dat het niet zo is.

[curry684]

TijnFLiP schreef op 10 maart 2003 @ 21:26:
Je hebt gelijk. Net gezien dat het creeren thread-safe is. Echter zou ik het sterk afraden ervan uit te gaan dat iets thread-safe is als je dat niet zeker weet. In het geval van Form creation is dat het geval omdat ze de constructor hebben 'beveiligd' met een TMultiReadExclusiveWriteSynchronizer. Echter toch ondersteund VCL geen forms in meerdere threads zie bijv (is wel BCB maar is ook VCL)

Windows GDI en User libs zijn niet threadsafe en gezien het feit dat VCL zelden synchronizeert is een VCL/CLX-app op Windows dus hoe dan ook niet tot nauwelijks threadsafe. Niet doen dus...

(hier doelde ik overigens op met: Op het moment dat je die term hebt opgezocht <...> kunnen we verder babbelen over het slechte design )

Want ik ben wel benieuwd of tokkie nu weet waarom z'n applicatie compleet lockte na het creeren van een thread?

[martijn_brinkers]

>>Goh op de NHL hebben ze vast en zeker Win95/98 en ME machines om op te >>developen, dat is namelijk het enige type OS waarop je dit soort fantastische >>thread starvation (zoek eens op wat het betekent) kunt reproduceren

Volgens mij heeft win9X geen last van "thread starvation" in de gebruikelijke zin van het woord dwz als je twee threads hebt van gelijke prioriteit dan krijgen ze beide een deel van de CPU tijd.

>>Windows GDI en User libs

Windows GDI is makkelijk thread safe te maken. Welke User libs bedoel je? want de win32 API is bijna volledig thread safe

>>Want ik ben wel benieuwd of tokkie nu weet waarom z'n applicatie compleet >>lockte na het creeren van een thread?

Ik hoop het maar het heeft niks te maken met thread starvation of het gebruik van sleep. Ben het er wel mee eens dat zn design volledig moet worden aangepast.

[ Voor 44% gewijzigd door martijn_brinkers op 10-03-2003 21:58 ]

[curry684]

TijnFLiP schreef op 10 maart 2003 @ 21:54:
Volgens mij heeft win9X geen last van "thread starvation" in de gebruikelijke zin van het woord dwz als je twee threads hebt van gelijke prioriteit dan krijgen ze beide een deel van de CPU tijd.

Nonsens. Als op 9x een thread nooit yield komt de hele rest van het proces zelden tot nooit aan de beurt. Pas als ze allebei yielden kan er evenredig verdeeld worden.

Windows GDI is makkelijk thread safe te maken.

Sja alles is makkelijk threadsafe te maken door de implementer. Het is echter in VCL niet gebeurd, en daar wees ik op.

Welke User libs bedoel je? want de win32 API is bijna volledig thread safe

Wellicht hier en daar per ongeluk, maar niet structureel. Ergo je wordt dringend geadviseerd er nooit van uit te gaan. Je zegt het ook zelf: "als je niet zeker weet dat het multi-thread-safe is ga er dan vanuit dat het niet zo is".

>>Want ik ben wel benieuwd of tokkie nu weet waarom z'n applicatie compleet
>>lockte na het creeren van een thread?
Ik hoop het maar het heeft niks te maken met thread starvation of het gebruik van sleep.

Mag jij mij uitleggen waarom dan wel

[martijn_brinkers]

Win9X zorgt ervoor dat wanneer meerdere threads van dezelfde prioriteit tegelijk actief zijn dat de CPU tijd everedig wordt verdeeld over deze threads zodat er geen thread starvation is. zie bijv:

Some systems, such as Windows 95, fight selfish thread behavior with a strategy known as time-slicing.

http://www.ecs.umass.edu/...ava/threads/priority.html


Win32 API is niet hier en daar per ongeluk thread safe. Het is juist bewust bijna helemaal thread safe. Het probleem bij Delphi is dat er hier en daar globale structuren zijn die (achteraf?) moeilijk thread safe zijn te krijgen maar dat ligt niet aan Win32 API.

Al zou Tokkie Sleep in zn thread procedure gebruiken dan zou zn probleem nog niet zijn opgelost omdat het niks te maken heeft met thread starvation. Dat zou wel een probleem kunnen zijn als je een high priority thread maakt met een tight loop zonder sleep. Dan heb je wel last van thread starvation tov de andere (lagere prioriteit) threads.

[curry684]

TijnFLiP schreef op 10 March 2003 @ 22:19:
Win9X zorgt ervoor dat wanneer meerdere threads van dezelfde prioriteit tegelijk actief zijn dat de CPU tijd everedig wordt verdeeld over deze threads zodat er geen thread starvation is. zie bijv:

Some systems, such as Windows 95, fight selfish thread behavior with a strategy known as time-slicing.

http://www.ecs.umass.edu/...ava/threads/priority.html

Heel leuk voorbeeld, maar je vergeet de belangrijkste quote:
"For example, this stand-alone Java program (which is based on the RaceApplet above) creates two equal priority selfish threads that have the following run() method."

Tokkie had in zijn programma maar EEN selfish thread, en 1 die netjes iedere paar instructies impliciet yield (in GetMessage om precies te zijn).

Win32 API is niet hier en daar per ongeluk thread safe. Het is juist bewust bijna helemaal thread safe. Het probleem bij Delphi is dat er hier en daar globale structuren zijn die (achteraf?) moeilijk thread safe zijn te krijgen maar dat ligt niet aan Win32 API.

Ik denk dat je het echt niet snapt. Stel dat de Win32 API threadsafe zou zijn. Dit zou betekenen dat er aan 1 van deze 2 condities voldaan moet worden:
• Iedere functie lockt een globale mutex. Dit houdt in dat alle API-calls serialized worden uitgevoerd wat het threadsafe maakt.
• Ieder systeemobject (Window, Pen, Brush, DC, Bitmap, Icon etc.) heeft een unieke mutex of critical section aan boord. Iedere call die het betreffende object gebruikt lockt de related mutexes. Dit zorgt ervoor dat alle calls op dat ene type serialized en dus threadsafe worden uitgevoerd.

De eerste optie is totaal onzinnig, ivm de mogelijkheden tot interprocess handlesharing zou dit voor iedere API-call een global lock inhouden. Dit is totaal onaanvaardbaar voor een systeem, het zou namelijk inhouden dat een willekeurige bug in de API's je hele systeem op kan blazen. En dat gaat tegen alle beginselen van het bouwen van een stabiel OS in.

De 2e optie is eveneens totaal onzinnig. In 99.99999% van de gevallen is het namelijk onnodig om threadsafe te werken, omdat slimme programmeurs hun GUI's in 1 thread schrijven door correct van de message pump gebruik te maken. De rest van de threads is puur worker threads die via messages (jaja) of andere IPC/synchronization hun werk terugkoppelen naar de main thread. Dus voor een verwaarloosbaar klein aantal van de gevallen sta je voor alle systeemobjecten een entry te maken in de global kernel-namespace. Ter voorbeeld waar je het dan over hebt: Winamp3.exe heeft op dit moment bij mij 175 normale handles en 2455 GDI-objects openstaan. De iexplore.exe waarin ik dit tik zit op 659 handles en 888 GDI-objects. Reken systeemwide op vele tienduizenden entries die continu beheerd dienen te worden. Dit is een volstrekt onacceptabele verspilling van resources.

Daarnaast is het zo dat veel API-functies meerdere objecten als parameter meenemen. Deze dienen ze allemaal te locken, waardoor een alleszins groot risico op deadlocks ontstaat als ze niet constant in dezelfde volgorde gelocked worden.

Je hebt overigens op 1 punt wel gelijk: er is een gedeelte van de Win32 API threadsafe, om precies te zijn het messagepump mechanisme. Niet zozeer als cadeautje aan de gebruiker, maar omdat ze nu eenmaal aan een thread vastzitten ipv een process zodat je meerdere independent windows in meerdere threads kunt managen (!!!!). Dit staat je ook toe om tussen 2 of meer threads PostMessage te gebruiken als IPC.

Al zou Tokkie Sleep in zn thread procedure gebruiken dan zou zn probleem nog niet zijn opgelost omdat het niks te maken heeft met thread starvation. Dat zou wel een probleem kunnen zijn als je een high priority thread maakt met een tight loop zonder sleep. Dan heb je wel last van thread starvation tov de andere (lagere prioriteit) threads.

Thread starvation betekent niet automatisch dat een thread niet meer aan de beurt komt, zie mijn post om 16:19:

Ik denk dat je niet echt lang gewacht hebt op het resultaat, na 5 minuten had je vast en zeker wat moeten zien

Het gaat hier om een thread die netjes constant yield tegenover eentje die nooit yield en blijft racen. Historische timeslicing schrijft voor dat de eerste weinig runtime krijgt omdat ie nu eenmaal in vergelijking met de tweede minder CPU-tijd vraagt. Omdat de 2e blijft racen wordt ie op een gegeven moment op de max ingedeeld van wat ie kan krijgen, wat inhoudt dat de message pump uit de main thread nauwelijks nog werkt. In die eindeloze loop een simpele Sleep(0) plaatsen zou het probleem al redelijk oplossen maar je blijft met 100% CPU load zitten.

Overigens heb ik ondertussen al 5 keer of zo gevraagd om jouw verklaring maar je blijft hardnekkig eromheen lullen. Ik ben nog steeds benieuwd....

[martijn_brinkers]

Overigens heb ik ondertussen al 5 keer of zo gevraagd om jouw verklaring maar je blijft hardnekkig eromheen lullen. Ik ben nog steeds benieuwd

Sorry, misschien begrijpen we elkaar verkeerd. Mijn verklaring voor zijn probleem is dat VCL niet thread safe is. Dat heeft niks te maken met thread starvation en dus zal sleep geen oplossing zijn voor zijn probleem. Je mag gewoon geen VCL forms in verschillende threads gebruiken. Zie (zoals ik al had gezegd)

http://tinyurl.com/77x4

Tokkie had in zijn programma maar EEN selfish thread, en 1 die netjes iedere paar instructies impliciet yield (in GetMessage om precies te zijn).

Wat maakt dat nou uit. Een selfish thread of twee, leg eens uit

Thread starvation betekent niet automatisch dat een thread niet meer aan de beurt komt, zie mijn post om 16:19:

Nou als je het hebt over 5 min w8en........

Ik denk dat je het echt niet snapt. Stel dat de Win32 API threadsafe zou zijn. Dit zou betekenen dat er aan 1 van deze 2 condities voldaan moet worden:

Iedere functie lockt een globale mutex. Dit houdt in dat alle API-calls serialized worden uitgevoerd wat het threadsafe maakt.

Ieder systeemobject (Window, Pen, Brush, DC, Bitmap, Icon etc.) heeft een unieke mutex of critical section aan boord. Iedere call die het betreffende object gebruikt lockt de related mutexes. Dit zorgt ervoor dat alle calls op dat ene type serialized en dus threadsafe worden uitgevoerd.

Er is nog een 3e mogelijkheid die in de meeste gevallen wordt gebruikt en voldoende is. Dat is nl een gewone functie met parameters op de stack en het gebruik van thread vars. Je hebt dus in veel gevallen helemaal geen mutexes nodig zoals jij beweerd om toch thread safe code te maken. Dus niet alle API functies moeten ineens met Mutexes dan wel critical sections gaan werken.

Daarnaast is het zo dat veel API-functies meerdere objecten als parameter meenemen. Deze dienen ze allemaal te locken, waardoor een alleszins groot risico op deadlocks ontstaat als ze niet constant in dezelfde volgorde gelocked worden.

Win32 API functies werken vaak niet met objecten maar gewoon Integers, chars etc. Win32 API is een zeer low level API, als je het hebt over objecten dan denk ik dat je het voornamelijk over COM objecten hebt maar dan hebben we het niet meer over win32 API.

[curry684]

Tering jij hebt de klok heel hard horen luiden maar de klepel hangt ergens op een andere planeet of zo. Nee stel je voor dat de User-functies van de Win32API een HWND oftewel Handle naar Window OBJECT mee zouden nemen. Stel je voor dat er globale lijsten van desktop windows bestaan. Stel je voor dat er binnen een window shared lijsten bestaan van z'n childwindows. Stel je voor dat er wel eens op globale of shared lijsten gesynchroniseerd zou moeten worden bij multithreaded toegang...

Kun je even bij je profiel vermelden hoe oud je bent? Ik word ondertussen benieuwd...

Ga asjeblieft een keer een interessant boek lezen binnenkort. Petzold kun je nog wel wat van leren.

[LordLarry]

curry684 schreef op 10 maart 2003 @ 23:08:
Overigens heb ik ondertussen al 5 keer of zo gevraagd om jouw verklaring maar je blijft hardnekkig eromheen lullen. Ik ben nog steeds benieuwd....

Mag ik het zeggen? Mag ik het zeggen? Mag ik het zeggen?

Na het opstarten van de thread wordt het form gecreerd. Dat is geen probleem. Het probleem komt pas hierna:

Delphi:

  repeat 
  until Application.Terminated; 

Deze loop is zo tight dat thread starvation optreed en geen enkele andere thread meer aan de beurt komt. Ook de main thread van het programma niet meer om de windows messages (of Qt events) af te handelen.

Je zou bijvoorbeeld een Sleep functie in de loop zetten zodat de loop 'langzamer' gaat lopen en zo meer tijd overblijft voor de andere threads. Of nog beter: Gebruik een mutex, event of semaphore zodat je de thread helemaal stopt todat het form aangeeft dat het genoeg is. Maar dan is ook meteen het hele doel van een thread teniet gedaan.

Dit allemaal afgezien of het verstandig/mogelijk/zinnig is om een form in een thread te creeeren.

[curry684]

LordLarry schreef op 11 maart 2003 @ 10:01:
Je zou bijvoorbeeld een Sleep functie in de loop zetten zodat de loop 'langzamer' gaat lopen en zo meer tijd overblijft voor de andere threads.

Een Sleep(0) is in principe voldoende. Ondanks dat de slaaptijd nul is is het wel een yield, oftewel alle pending threads komen per direct aan de beurt. Zoals gezegd blijf je dan wel op 100% load hangen

[Verwijderd]

Allereerst snap ik nog niet wat nu de oorzaak is waarom mijn 1e idee niet goed werkt. Ik weet nu wat dat thread starvation inhoudt, maar ik zie niet de oorzaak daarvan.

Maar ik zal eerst nog ff het hele idee uitleggen:

Teneerste gebruiken we dus linux als platform en GEEN VCL maar CLX.

We gaan 1 applicatie maken die gebruikt gaat worden voor de besturing/informatie voorziening van 4 bowling banen.

Iedere bowlingbaan heeft de beschikking over een joystick, waarmee de gebruiker het systeem kan bedienen.

De applicatie met de 4 onafhankelijk van elkaar werkende schermen moet reageren op:

-jostick
-bal detectie sensor (dus als er een bal gegooid is)
-communicatie (als er een bericht van de centrale computer binnenkomt op een TCP server socket)

Voor de joystick, bal detectie zal een aparte IOHandling thread gebruikt worden die continu kijkt of er op 1 van de 4 banen een actie heeft plaats gevonden.

Ook zal er een TCPServer thread draaien, die continu aan het luisteren is, of er commando's van de centrale computer komen.

Als de gebruiker nu op baan 1 op de vuurknop drukt komt het scherm op baan 1 in het invoer scherm voor de namen.

Als er dus een input signaal optreedt zal de IOHandling thread dit signaal door sturen naar het formulier op baan 1. Het formulier op baan 1 zal dit signaal verder afhandelen door de code uitvoeren.

Maar als deze code nu vrij veel tijd inbeslag zou nemen en ondertussen drukt iemand op baan 3 op de vuurknop dan zal de IOThread dat uiteraard wel zien, maar hij kan het niet direct door sturen naar het formulier op baan 3 omdat de code van de vuurknop afhandeling op baan 1 nog bezig is.

Je kan dus situaties krijgen dat een bepaalde baan niet goed meer reageert.

Dat is ook de reden dat ik dacht om die formulieren op de 4 banen in aparte threads te zetten.

Heeft iemand misschien een beter idee?

[curry684]

Verwijderd schreef op 11 maart 2003 @ 11:07:
Allereerst snap ik nog niet wat nu de oorzaak is waarom mijn 1e idee niet goed werkt. Ik weet nu wat dat thread starvation inhoudt, maar ik zie niet de oorzaak daarvan.

Zie LordLarry's post.

Teneerste gebruiken we dus linux als platform en GEEN VCL maar CLX.

Zelfde.

Als er dus een input signaal optreedt zal de IOHandling thread dit signaal door sturen naar het formulier op baan 1. Het formulier op baan 1 zal dit signaal verder afhandelen door de code uitvoeren.

PostMessage(MainWindow, WM_USER + 1, BaanNummer, EventStructuur);
Eep, Windowsoplossing, excusez-moi. Je kunt het hoe dan ook oplossen met events, mutexes, of als meest charmante een pipe.

Maar als deze code nu vrij veel tijd inbeslag zou nemen en ondertussen drukt iemand op baan 3 op de vuurknop dan zal de IOThread dat uiteraard wel zien, maar hij kan het niet direct door sturen naar het formulier op baan 3 omdat de code van de vuurknop afhandeling op baan 1 nog bezig is.

Exact wat voor kolengebrande machine was je dit van plan te draaien?

Tenzij je dit echt op een 486 gaat draaien moet je je echt gaan schamen als de eventhandling ooit langer dan 50ms bezig is...

Heeft iemand misschien een beter idee?

Event-driven.

[ Voor 6% gewijzigd door curry684 op 11-03-2003 11:14 ]

[Aetje]

Dit progsel gaat dus -nooit- werken op deze manier. Je maakt een form aan binnen een thread. Dat is sowieso al vaud, een form is een visueel object, en alle visuele objecten binnen Object Pascal (dus ook Kylix) moeten in de main VCL thread behandeld worden. Verder eindig je de loop met een "repeat until TRUE" constructie. Sleep tussen gooien of je krijgt een thread die CPU tijd zuipt waar je niet goed van wordt...

Tenslotte: De procedures van het in de thread gecreerde form worden niet binnen die thread uitgevoerd. Wat je wil lukt dus ook niet echt. Beter idee? De TThreads binnen het form object aanmaken en de -echte- code die je er aan wil knopen in de execute zetten. Houdt er rekening mee dat je een vorm van synchronisatie moet gebruiken om visuele objecten te manipuleren vanuit de thread...

[Verwijderd]

Kijk eens bij TThread.Synchronize.

Zelf heb ik trouwens een hekel aan TTimers aangezien ze in Windows beperkt worden door het OS zelf. Ook daar kun je beter een TThread voor bouwen imho.

[Verwijderd]

curry684 schreef op 11 March 2003 @ 11:12:
Exact wat voor kolengebrande machine was je dit van plan te draaien?

Tenzij je dit echt op een 486 gaat draaien moet je je echt gaan schamen als de eventhandling ooit langer dan 50ms bezig is...
Event-driven.

Het zal gewoon op een super snelle AMD bak gaan werken. Maar stel nou dat je in die events code ga zetten dat je bijvoorbeeld wat wegschrijf in een database (via netwerk) of iets moet lezen van een schijf, of in ons geval een foto'tje maak van de omgevallen pins en die vervolgens opsla.

Het is behoorlijk irritant als de gebruiker op een andere baan met de joystick zijn naam aan het invoeren is en dat het niet goed (snel) reageert.

Maar Curry jij denkt dus dat dat geen probleem zou moeten opleveren?

[LordLarry]

Verwijderd schreef op 11 March 2003 @ 11:31:
Het zal gewoon op een super snelle AMD bak gaan werken. Maar stel nou dat je in die events code ga zetten dat je bijvoorbeeld wat wegschrijf in een database (via netwerk) of iets moet lezen van een schijf, of in ons geval een foto'tje maak van de omgevallen pins en die vervolgens opsla.

Dan is dat de ideale kandidaat voor een thread. Alleen de functie dus die zoveel tijd kost. Het form niet. Het form is hier niet eens aan te pas gekomen want het komt als reactie op een IO event. Dat er toevallig wat weergegeven wordt op een form is van ondergeschikt belang.

[curry684]

Verwijderd schreef op 11 maart 2003 @ 11:31:
[...]
Het zal gewoon op een super snelle AMD bak gaan werken. Maar stel nou dat je in die events code ga zetten dat je bijvoorbeeld wat wegschrijf in een database (via netwerk) of iets moet lezen van een schijf, of in ons geval een foto'tje maak van de omgevallen pins en die vervolgens opsla.

Maar Curry jij denkt dus dat dat geen probleem zou moeten opleveren?

Sja het lijkt me sterk dat DB-access, network access of imageprocessing merkbare vertragingen zouden opleveren. Indien het 'dead-end' functionaliteit betreft (geen feedback required) kun je het zeker in een thread doen, maar ik zou dat pas doen als je echt zeker weet dat het inline te traag is om potentieel crashwerk met synchronizatie e.d. te voorkomen.

[martijn_brinkers]

curry684 schreef op 11 maart 2003 @ 00:04:
Tering jij hebt de klok heel hard horen luiden maar de klepel hangt ergens op een andere planeet of zo. Nee stel je voor dat de User-functies van de Win32API een HWND oftewel Handle naar Window OBJECT mee zouden nemen. Stel je voor dat er globale lijsten van desktop windows bestaan. Stel je voor dat er binnen een window shared lijsten bestaan van z'n childwindows. Stel je voor dat er wel eens op globale of shared lijsten gesynchroniseerd zou moeten worden bij multithreaded toegang...

Kun je even bij je profiel vermelden hoe oud je bent? Ik word ondertussen benieuwd...

Ga asjeblieft een keer een interessant boek lezen binnenkort. Petzold kun je nog wel wat van leren.

Zo zo... stoere taal. Heb je uberhaupt gelezen wat hier staat ?http://tinyurl.com/77x4

Weet jij uberhaupt wel wat thread-safe is? Zo te merken niet. Zo ja wil jij mij dat dan eens uitleggen?

[Verwijderd]

We hebben het hier nog eens over het ontwerp gehad en zijn tot de volgende 2 opties gekomen:

Optie a: (Plaatje)

Bij dit ontwerp is er dus 1 applicatie die bestaat uit een Main form, TCP server thread, input handling thread.

In het main formulier wordt een LaneComputer instantie gecreeerd die vervolgens 2 of 4 BowlingLane instanties aanmaakt. Als er nu een input binnenkomt op de Input handling thread dan zal die doorgestuurd worden naar het juiste BowlingLane instantie. Als er nu veel code uitgevoerd moet worden, dan zal dat vervolgens d.m.v. een aparte thread verder uitgevoerd worden.


Optie b:(Plaatje)

Bij dit ontwerp is er 1 Hoofdapplicatie die bestaat uit een Main form, TCP server thread en input handling thread.

Vervolgens worden uit de database de gegevens opgehaald om zo te zien voor hoeveel bowlingbanen deze pc zal dienen.

Dan zullen er zoveel APARTE applicaties gestarten worden! (Dus het zijn allemaal dezelfde applicaties, maar ze worden meerdere keren opgestart.) Bij het starten wordt een parameter mee gegeven die aangeeft voor welk baannummer deze applicatie bedoeld is. Het grote voordeel van deze optie is dat als er 1 applicatie vast loopt de andere 3 banen gewoon verder kunnen werken + als er bij 1 baan toch code uitgevoerd wordt wat toch lang blijkt te duren, de andere banen daar geen last van zullen hebben.

Graag hoor ik jullie meningen over deze 2 opties.

[martijn_brinkers]

Even een voorbeeld progje voor Curry684 om te laten zien dat thread starvation geen probleem is. Dus dat zijn probleem niet op te lossen is met Sleep ofzo. Het is een VCL probleem... maar nee.... jij blijft maar hameren op sleep. Probeer het maar.... creeer 10 threads.... de 2 button blijft reageren en zal een dialogbox naar voren brengen. Ook getest op win98 (maar dan met VMWare dus dat zal je wel niet goed genoeg vinden).

code:

unit main;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;



type

  TStarve = class(TThread)
  private
    { Private declarations }
  protected
    procedure Execute; override;
  end;

  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

procedure TStarve.Execute;
begin
  { Place thread code here }
  while not Terminated do
  begin
  end;
end;


{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  TStarve.Create( False );
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
  MessageDlg('Test', mtWarning, [mbOK], 0);
end;

end.

[Verwijderd]

Wij zouden zelf het liefst optie b gaan uitvoeren. Maar zitten er technisch gezien geen nadelen aan deze optie?

[OxiMoron]

Verwijderd schreef op 10 March 2003 @ 16:15:
[...]
Ik zit niet op het NHL, maar op de HR (Hogeschool Rotterdam). Maar momenteel ben ik aan het afstuderen bij een bedrijf en ontwikkel hier met kylix op een SuSE 8 machine.

Hihi..

wij moesten halverwege het 2e jaar namelijk ook een bowl applicatie maken..
maar aangezien dit je afstudeer opdracht is zal het wel wat ingewikkelder zijn

[Verwijderd]

OxiMoron schreef op 12 March 2003 @ 08:49:Hihi..

wij moesten halverwege het 2e jaar namelijk ook een bowl applicatie maken..
maar aangezien dit je afstudeer opdracht is zal het wel wat ingewikkelder zijn

Wat moest de applicatie bij jullie precies doen?

[LordLarry]

TijnFLiP schreef op 11 maart 2003 @ 15:47:
Even een voorbeeld progje voor Curry684 om te laten zien dat thread starvation geen probleem is. Dus dat zijn probleem niet op te lossen is met Sleep ofzo. Het is een VCL probleem... maar nee.... jij blijft maar hameren op sleep.

Het voorbeeld dat je geeft zorgt er idd niet voor dat heel Windows vastloopt, maar je moet toegeven dat windows niet meer lekker loopt. Er wordt nogsteeds wel gereageerd, maar wel naar een duidelijk merkbare vetraging. En dit terwijl de thread niets doet. In jouw voorbeeld wordt niet eens de VCL gebruikt, dus je hebt met je voorbeeld al aangegeven dat het zeker niet de VCL is die het probleem veroorzaakt. Wat al een onmiddelijke verbetering in je voorbeeld is, is het gebruik van Sleep in het loopje. Via Sleep(0) geeft de thread aan dat ie (voorlopig) klaar is en dat de timeslice die aan deze thread is gegeven wel aan een andere kan gegeven worden. Meteen wordt de GUI sneller, maar de CPU load blijft nog wel op 100% staan. Door een hoger getal aan Sleep mee te geven wordt dit omlaag gebracht...

/edit
Aangezien de TS Kylix gebruikt , maakt ie bovendien niet gebruik van VCL, maar CLX en die is gebouwd bovenop Qt. Qt werkt niet geheel hetzelfde als win32 en de effecten die ik hierboven beschreven heb zullen misschien niet iets erger zijn onder Qt zodat wel de hele GUI lijkt vast te lopen.

Bovendien, als iets niet threadsafe is zal je rare verschijnsellen krijgen en excepties, maar hoogstwaarschijnlijk geen 'vastgelopen' GUI.

[ Voor 17% gewijzigd door LordLarry op 12-03-2003 09:34 ]

[curry684]

LordLarry schreef op 12 maart 2003 @ 09:29:
[...]
Het voorbeeld dat je geeft zorgt er idd niet voor dat heel Windows vastloopt, maar je moet toegeven dat windows niet meer lekker loopt. Er wordt nogsteeds wel gereageerd, maar wel naar een duidelijk merkbare vetraging.

Waarbij je 2 dingen in het achterhoofd moet houden, nl. dat het OS bij tokkie ook niet vastliep maar alleen de huidige applicatie. Thread starvation op OS-niveau kan pas optreden zodra je process priorities verneukt, en een process intern verneuken is makkelijker omdat het minder snel fataal is.

Ten tweede ging het over Linux en niet Windows. Linux doet voor zover ik weet aan historisch thread scheduling, oftewel een thread die structureel z'n werk niet gedaan krijgt (gekicked wordt voordat ie yield) krijgt een steeds hogere prioriteit. Dit gaat op dat moment zelfs ten koste van de netjes yielding threads omdat al die threads dezelfde prioriteit hebben en dus theoretisch hetzelfde recht om hun werk af te krijgen. Wat er in principe gebeurt is dat Thread A starved omdat de task scheduler denkt dat Thread B ligt te starven omdat ie z'n werk consequent niet afkrijgt.

Het 2e weet ik overigens niet zeker.

[Verwijderd]

Het is een leuke discussie aan het worden

Maar ik zelf ben nu graag geinteresseerd in het nieuwe ontwerp.

Het 1e ontwerp, waar jullie het nu nog steeds over hebben, blijkt dus echt verkeerd te zijn.

Graag hoor ik daarom jullie reactie's over de 2 nieuwe ontwerpen. (zie een paar reply's terug).

Wat vinden jullie daarvan?

[curry684]

Verwijderd schreef op 12 maart 2003 @ 10:01:
Het 1e ontwerp, waar jullie het nu nog steeds over hebben, blijkt dus echt verkeerd te zijn.

Relatief. We kraken het ontwerp niet specifiek af maar je implementatie

_{Ja het ontwerp was ook zwaar fout, maar wel levensvatbaar}

[edit]
Van de 2 opties die je noemt is nummer B ruim de meest levensvatbare, alhoewel ik zelf nog steeds voor een compleet singlethreaded approach zou kiezen omdat ik niet inzie hoe je in godesnaam grotere delays dan 50ms zou willen veroorzaken.

En zelfs al heb je grote delays, ik ga ervan uit dat CLX ook Application->ProcessMessages() kent dus dan heb je nog steeds geen probleem.

(wink at LordLarry, dit is weer een van de uitzonderlijke gevallen dat die functie acceptabel is )

[ Voor 43% gewijzigd door curry684 op 12-03-2003 10:48 ]

[Verwijderd]

curry684 schreef op 12 maart 2003 @ 10:44:
[...]

Relatief. We kraken het ontwerp niet specifiek af maar je implementatie

_{Ja het ontwerp was ook zwaar fout, maar wel levensvatbaar}

Maar zou je nu voor optie a of b kiezen?

Wat bij ons het belangrijkste is dat de 4 schermen van de 4 verschillende banen zo min mogelijk afhankelijk van elkaar zijn. En dat als er 1 vastloopt de andere 3 gewoon blijven werken.

[ Voor 25% gewijzigd door Verwijderd op 12-03-2003 10:50 ]

[Aetje]

Dan splits je het project in volledig afgescheidde applicaties op:
- 4x een BowlingBaan control appje
- 1x een communicatie appje wat enige hardware op de banen regelt

Deze appjes communiceren dan als een soort client-server iets. Lijkt me een handiger ontwerp als het zaakje moet blijven lopen. Crasht een control appje... Restart.