Jag har tidigare kört väldigt enkla trådningar av mina små applikationer utan någon större tanke på synkronisering och annat som kan vara bra att ha koll på och nu när jag konverterade ett gammalt projekt till vs.net 2k5, så dök det upp en del varningar på Thread.Suspend(), Thread.Resume() om att dessa är på väg att försvinna och att man hellre ska använda sig utav Monitor, Mutex, Event och Semaphore.
Jag skulle behöva lite hjälp på traven när det gäller att starta en tråd "rätt" och hur jag sedan kan använda pause/resume. Av vad jag hittils läst på msdn verkar Monitor passa min app bra nu och att det går med Wait och Exit, men jag skulle väldigt gärna vilja se ett fungerande exempel om någon av er sitter på något.
Det min applikation har tänkt göra är att räkna ut saker. Problemet är att i dagsläget tar det cirka ett dygn att räkna klart allting så jag behöver kunna stoppa/pausa räknaren när jag vill.
Det är en massa olika funktioner som körs från en "start"-funktion och för tillfället ser det ut såhär ungefär
private Thread appThread;
appThread = new Thread( new ThreadStart( mainFunction ) );
appThread.Name = "EttNamn";
appThread.Start();
Thread.Sleep( 0 );
För att pausa använder jag helt enkelt mig utav
appThread.Suspend();
appThread.Resume();
Och så ska man visst inte göra :) Jag har kikat lite på mutex, men det verkar vara overkill.
Jag är fortfarande nyfiken på ett exempel med suspend/resume om någon har ett fungerande sådant.
Det min applikation har tänkt göra är att räkna ut saker. Problemet är att i dagsläget tar det cirka ett dygn att räkna klart allting så jag behöver kunna stoppa/pausa räknaren när jag vill.
Det är en massa olika funktioner som körs från en "start"-funktion och för tillfället ser det ut såhär ungefär
private Thread appThread;
appThread = new Thread( new ThreadStart( mainFunction ) );
appThread.Name = "EttNamn";
appThread.Start();
Thread.Sleep( 0 );
För att pausa använder jag helt enkelt mig utav
appThread.Suspend();
appThread.Resume();
Och så ska man visst inte göra :) Jag har kikat lite på mutex, men det verkar vara overkill.
Jag är fortfarande nyfiken på ett exempel med suspend/resume om någon har ett fungerande sådant.
Ha en bool (isPaused) som du kollar i din tråd. Är isPaused true så låter du tråden sova i valfri tid. Är den false så kör du din beräkning.
Message: Thread.Suspend has been deprecated because code that uses it is very deadlock-prone. Synchronization of threads or mutually-exclusive access to protected resources should be accomplished using other classes in System.Threading, such as Monitor, Mutex, Event, and Semaphore.
Resume()
Message: Thread.Resume has been deprecated because code that uses it is very deadlock-prone. Synchronization of threads or mutually-exclusive access to protected resources should be accomplished using other classes in System.Threading, such as Monitor, Mutex, Event, and Semaphore
Visst har microsoft underlättat det för utvecklarna med .NET framework jämfört med andra utvecklings frameworks, men att dom dumförklarar utvecklarna genom att göra kod obsolete för göra att folk inte gör misstag det trodde jag inte.
Men dom har ju rätt oftast så går det att lösa snyggare med det dom nämner, men ändå :|.
Message: Thread.Suspend has been deprecated because code that uses it is very deadlock-prone. Synchronization of threads or mutually-exclusive access to protected resources should be accomplished using other classes in System.Threading, such as Monitor, Mutex, Event, and Semaphore.
Resume()
Message: Thread.Resume has been deprecated because code that uses it is very deadlock-prone. Synchronization of threads or mutually-exclusive access to protected resources should be accomplished using other classes in System.Threading, such as Monitor, Mutex, Event, and Semaphore
Visst har microsoft underlättat det för utvecklarna med .NET framework jämfört med andra utvecklings frameworks, men att dom dumförklarar utvecklarna genom att göra kod obsolete för göra att folk inte gör misstag det trodde jag inte.
Men dom har ju rätt oftast så går det att lösa snyggare med det dom nämner, men ändå :|.
Det är väl alldeles utmärkt att de tar bort något som är dålig praxis att använda. Det är inte helt sällan som man klagar på windows när en applikation kraschar. Genom detta så ger de utvecklaren chansen att koda på rätt sätt.
Jag tycker att de skulle ha kvar det gamla och lägga in det nya samtidigt.
Som Phorpher sa så är det väl ingen ide att ha kvar metoder som har en läggning att orsaka buggar som även är ini #"¤%&# svåra att hitta om man inte vet vart man ska leta...
Min lösning med Thread.Sleep( Timeout.Infinite ) verkar inte vara någon bra lösning eller så måste jag hitta på något annat här. Hela applikationen tvärlåser sig, men det kanske är vad jag bör förvänta mig?
Som Phorpher sa så är det väl ingen ide att ha kvar metoder som har en läggning att orsaka buggar som även är ini #"¤%&# svåra att hitta om man inte vet vart man ska leta...
Min lösning med Thread.Sleep( Timeout.Infinite ) verkar inte vara någon bra lösning eller så måste jag hitta på något annat här. Hela applikationen tvärlåser sig, men det kanske är vad jag bör förvänta mig?
Dela en Mutex mellan beräkningstråden och din huvudtråd (GUI eller vad det nu är.) Låt beräkningstråden köra mutex.WaitOne(); för att se om mutexen är "ledig". När du vill pausa så låter du huvudtråden köra WaitOne(); för att plocka åt sig mutexen och därmed blockeras beräkningstråden tills ReleaseMutex() körs från huvudtråden.
Fick samma bekymmer här tyvärr. När jag kör WaitOne() i huvudtråden låser det upp sig rejält.
Jag vet att jag gör fel någonstans, men jag vet inte riktigt vad det är som går snett. Behöver arbetartråden vara static?
Mitt förslag förutsätter att beräkningstråden inte låser upp mutexen under längre stunder. Om den gör det så kommer ett eventuellt GUI låsa sig tills dess att beräkningstråden släpper mutexen.
Mitt förslag förutsätter att beräkningstråden inte låser upp mutexen under längre stunder. Om den gör det så kommer ett eventuellt GUI låsa sig tills dess att beräkningstråden släpper mutexen.
Kan du bifoga lite kod kanske?
Jag insåg precis att ett ManualResetEvent kan vara bättre för dig. Låt huvudtråden släppa ditt ManualResetEvent (mre.Set()) för att få beräkningstråden att exekvera. När huvudtråden vill pausa kör den mre.Reset().
I beräkningstråden kör du mre.WaitOne() för att vänta på "körsignal".
