Archief - [PROG][C#] MultiThreading, programma werkt enkel op windows XP

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
D

DiDoria

Legacy Member
Hoi,

Mijn applicatie is stilaan af aan het raken en ik dacht het eens te testen op een windows 2000 server (er stond wel niet windows 2000 server op maar professional).
Nu, mijn programma crached na 10sec al... ik try, catch alles dus het lag min of meer niet aan het programma. Hij geeft echt een windows fout en vraag om het te debuggen dan (en dan de typische melding of je het wil versturen of niet naar MS).

Eerst dacht ik dat het lag aan de shellInterface die ik had gebruikt (die shell32.ddl gebruikt, heb ik van hier) en dat deze op windows 2000 anders was. Maar na in visual studio het programma te hebben uitgevoerd zag ik dat hij crachte het momment dat ik mijn threads begon om te starten (GUI en domein --> anders kan je niets displayen als hij aan het verwerken is). Ik heb alles dan eens 100% sequentieel gemaakt en dat werkt wel...
Is er nu iets met threading dat windows 2000 niet aankan? Moet ik iets instellen? Kent iemand dit probleem?

thx!
C

CyBeRRaT

Legacy Member
hey, ik zou hier het antwoord eigenlijk ook op willen weten, aangezien ik dit ook nodig ga hebben en het moet verplicht werken op windows2000
D

DiDoria

Legacy Member
Ik moet wel zeggen dat ik deze 3 warnings krijg (toevallig i.v.m. multithreading) maar weer stel ik me dan de vraag, Wrm werkt het dan op XP?:

Code: 
Warning	1	'log4net.Appender.FileAppender.FileAppender(log4net.Layout.ILayout, string)' is obsolete: 'Instead use the default constructor and set the Layout & File properties'	C:\Documents and Settings\AWYDZ\My Documents\Visual Studio 2005\Projects\Data Collector II\Data Collector II\domain\DAL\ApplicationDirector.cs	35	41	Data Collector II
Warning	2	'System.Threading.Thread.Suspend()' is obsolete: 'Thread.Suspend has been deprecated.  Please use other classes in System.Threading, such as Monitor, Mutex, Event, and Semaphore, to synchronize Threads or protect resources.  http://go.microsoft.com/fwlink/?linkid=14202'	C:\Documents and Settings\AWYDZ\My Documents\Visual Studio 2005\Projects\Data Collector II\Data Collector II\gui\ProgressPanel.cs	134	25	Data Collector II
Warning	3	'System.Threading.Thread.Resume()' is obsolete: 'Thread.Resume has been deprecated.  Please use other classes in System.Threading, such as Monitor, Mutex, Event, and Semaphore, to synchronize Threads or protect resources.  http://go.microsoft.com/fwlink/?linkid=14202'	C:\Documents and Settings\AWYDZ\My Documents\Visual Studio 2005\Projects\Data Collector II\Data Collector II\gui\ProgressPanel.cs	137	25	Data Collector II
C

CyBeRRaT

Legacy Member
blijkbaar zijn die functies deprecated, wat zoveel wil zeggen als: gebruik ze niet meer, want in toekomstige versies wordt dit geschrapt
D

DiDoria

Legacy Member
Ze zijn al uit het programma gehaald (vervangen door ThreadPool) maar hij blijft de zelfde fout geven. Dat was het dus niet.
C

CyBeRRaT

Legacy Member
hey,
ik heb er zelf ook wat mee zitten werken. wat ik heb ondervonden is dat je in een bepaalde thread enkel objecten mag wijzigen die ook in die thread zijn aangemaakt. als je dit niet doet, is er een kans dat je een crash krijgt (en met de debugger crasht het altijd!)

enige manier om dit te omzeilen is via delegates. dat werktte bij mij alles weer perfect
C

CyBeRRaT

Legacy Member
als jij een andere, betere manier weet om tijdens het inladen van een listbox het programma niet te locken en tegelijkertijd de listbox zelf geleidelijk aan te laten aanvullen, dan zal ik die manier gebruiken:)
U

UniKorn

Legacy Member
Op het ogenblik dat je listbox een gigantisch aantal elementen bevat heeft het imho geen nut om een listbox te gebruiken.
D

DiDoria

Legacy Member
CyBeRRaT zei:
hey,
ik heb er zelf ook wat mee zitten werken. wat ik heb ondervonden is dat je in een bepaalde thread enkel objecten mag wijzigen die ook in die thread zijn aangemaakt. als je dit niet doet, is er een kans dat je een crash krijgt (en met de debugger crasht het altijd!)

enige manier om dit te omzeilen is via delegates. dat werktte bij mij alles weer perfect
Klik om te vergroten...

Ik heb de klassen (waren interfaces naar windows eigenlijk) in een methode gestoken . Het werkt perfect nu... Dus wat je zegt klopt gwn :) Dat komt omdat ze niet Thread-Safe waren. Moet je dus altijd op letten.
En threading is wel noodzakelijk soms. Hoe kan je anders verwerking doen en ondertussen iets op je GUI tonen. 2threads zijn er wel vaker (vb muziek in een programma, filmpje, animatie, verwerking en displayen tegelijk, enz...) 3 is al af te raden (vind ik toch)

thx!
C

CyBeRRaT

Legacy Member
Moto zei:
Is dat dan zo een gigantische listbox?
hopelijk staat er een deftige filter op, anders arme users :p

@Cyberrat
voor uw ander probleem
is dit handig? -> http://blog.guymahieu.com/2006/11/15/systemdelegate-is-not-a-delegate-type/
Klik om te vergroten...

ja, het zijn inderdaad nogal veel regels. een kleine 600 om juist te zijn. we zijn momenteel eens aan het bekijken of we het niet gaan doen met iets anders, al blijft het probleem dan nog steeds.
heb nu de tijd niet om er eens naar te kijken, maar ga dat een van de dagen zeker doen
H

H@voc_!nc.

Legacy Member
600 zou geen probleem mogen zijn

probeer eens met uw
listbox.BEginUpdate();
try{
//Laadt uw items
}finally{
lisbox.EndUpdate();
}
C

CyBeRRaT

Legacy Member
probleem is dat de objecten die uit de database gehaald moeten worden nogal "complex" zijn (meerdere queries per object) en het duurt dus nog een dikke twee seconden tegen al die 600 objecten in de listview staan.
met die beginupdate gaat het in totaal iets sneller, maar je ziet niks gebeuren, waardoor het voor de gebruiker nog altijd lang overkomt.

daarom werkte ik met een aparte thread voor het inladen, waardoor je de lijst zag groeien. zeker niet optimaal, want het duurde lang. ook het feit dat het nog altijd aanzien werd aan thread-onveilig helpt niet echt....


EDIT: potentieel kan het aantal elementen na verloop van tijd wel oplopen naar meer dan 1000 gegevens. welke structuur raden jullie in dit geval dan aan?
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan