pause start i thread

Nu syns jeg lige det er svært at se din tankegang i koden, men ville kunne laves ved hjælp af en bool....

class
{
private volatile bool SkalKoresOccured;
private volatile bool run;

private void SkalKores(object sender, EventArgs args)
  //Normalt ser events jo ca. sådan ud, men har man selv lavet en
  //eventhandler kan de jo være anderledes
{
  SkalKoresOccured = true;
}

private void ThreadDerKore()
{
  while(run)
  {
  if(!SkalKoresOccured)
  {
    //Tråd hænger her til eventet skete, kan laves med en while evt. også
  }
  else
  {
    SkalKoresOccured = false;
    //Ud fra den antagels at eventet sker, så skal tråden lave sit
    //hendelsessforløb en gang og vente på eventet sker igen?, ellers væk med
    //linien SkalKoresOccured = false;

    //DO SOMETHING
  }
  }
}
}

var lige en lille hurtig måde det kunne gøres på... der er andre måder hvorpå det kan løses nok... men et bud

ups, run skal lige sættes til true når du starter, dette er fordi jeg selv normalt har en løkke der kører på run, bruger så run til at terminere tråden... der er igen self. masser af måde at gøre dette på, den while er også ud fra en tråd der kører "uendeligt", mens det jo kan være du har en tråd der bare skal kører en skrivning igennem for så at terminere... så kan du fjærne while løkken helt, du kan også returne/breake når oprationen er overstået... men hvis du har gang i trådning går jeg ud fra du ved disse ting :D

hmm. den der løsning er for nem jo :)

var den jeg selv havde overvejet..
men der må jo være en bedre løsning..!

ok.. forklare det lidt bedre..!

jeg skal sende noget info til com porten..!

så det min kode skal gøre er at:
åbne serielporten.
skrive til porten.
her kommer så det sted hvor at jeg skal vente på den event som fortæller at jeg modtager data på porten.
når mit program så har godkendt svaret, så skal den kører ny kode.
igen her skal jeg vente på porten.
osv

dvs

class
{
private void skalkores(data_recieved_event) //den event som skal køres
{
//kode
}

private void ThreadDerKore() //selve min thread
{
//er enhed forbundet serialporten???
//her skal så ventes på at der kommer svar på DataRecieved_event
//hvis der fåes positivt svar, så kør videre
//her skal igen ventes på datarecieved..!
//osv osv osv
}
}

Keep it simple, keep it stupid... Simpelt er kun godt i mine øjne ^^
Og hvad mener du med bedre præcis?...

jeg forsøger også så vidt muligt at køre udfra "kiss"

men engang imellem må man jo stille lidt krav..!

en bedre løsning..

jo.. din løsning..
den er simpel ja..

da dette er en del af en opstartsprocess, så forsøger jeg så vidt muligt at holde ressurcerne nede..!
det bliver ikke en lynhurtig computer det skal kører på, og det skal helst kunne starte hele systemet på MEGET kort tid.!

jeg vil mene at måden du gør det på, den måde vil kræve ekstra ressurcer, frem for at hvis man pausede min thread hver gang at den skulle bruge data..!
(grunden til at jeg vil køre den som thread er iøvrigt pga at jeg gerne vil have at den arbejder med de andre opstartselementer, mens at den sender lidt med min com port.!)

ahh ok så...
prøv med samme kode jeg giver dig ca. men... + noget ala: (er lige skrevet lidt kvikt;
______________________________________________________________________________________

class
{
private volatile bool SkalKoresOccured;
private volatile bool run;

private Thread dinThread;

private void SkalKores(object sender, EventArgs args)
  //Normalt ser events jo ca. sådan ud, men har man selv lavet en
  //eventhandler kan de jo være anderledes
{
  SkalKoresOccured = true;
  this.dinThread.Resume();
}

private void ThreadDerKore()
{
  while(run)
  {
  if(!SkalKoresOccured)
  {
    //Tråd hænger her til eventet skete, kan laves med en while evt. også
    this.dinThread.Suspend()
  }
  else
  {
    SkalKoresOccured = false;
    //Ud fra den antagels at eventet sker, så skal tråden lave sit
    //hendelsessforløb en gang og vente på eventet sker igen?, ellers væk med
    //linien SkalKoresOccured = false;

    //DO SOMETHING
    this.dinThread.Suspend()
  }
  }
}
}
_____________________________________________________________________________________

Hvis det er Thread klassen du arbejder med...

Sagen er dog at du så skal tænke dig godt om når du gør det... men det vil du kunne læse lidt om allerede i dokumentationen om Suspend metoden, den der desuden faktisk obsolete, men ved ikke hvad den er blevet erstattet af.. :S

Monitor Enter & Exit var en mulighed

eksempel:

/*
* Created by SharpDevelop.
* User: Arne
* Date: 26-05-2006
* Time: 18:12
*
* To change this template use Tools | Options | Coding | Edit Standard Headers.
*/
using System;
using System.Threading;

namespace E
{
    public class T
    {
        private object lck;
        public T(object lck)
        {
            this.lck = lck;
        }
        public void Run()
        {
            Console.WriteLine("Start");
            Monitor.Enter(lck);
            Console.WriteLine("Done");
        }
    }
    public class MainClass
    {
        public static void Main(string[] args)
        {
            object lck = new object();
            T t = new T(lck);
            Monitor.Enter(lck);
            (new Thread(new ThreadStart(t.Run))).Start();
            Console.Write("Press enter to continue ...");
            Console.ReadLine();
            Monitor.Exit(lck);
            Thread.Sleep(100);
        }
    }
}

arne_V
din metode er ikke meget anderledes en Md-Craig

dog bruger du semaphore(eller lock om man vil)

men begge er korrekte.. har dog kun prøvet Craigs version.. ender nok med at bruge Arne_V's pga der nok er mere kontrol over thread konflikter..! (modsig mig hvis jeg tager fejl)

men jeg forhøjer point til det dobbelte..!
og jeg er dårlig til at regne, så 2 * 60 bliver i mit hoved 200 :)
det er jo sent.. (ihvertfald for os der ikke bor i USA)
så ligger i et par svar.?

"men begge er korrekte.. har dog kun prøvet Craigs version.. ender nok med at bruge Arne_V's pga der nok er mere kontrol over thread konflikter..! (modsig mig hvis jeg tager fejl)"

Hehe... vil jeg på ingen måde modsige ;)

hmm. bliver lige nød til at vente til arne også ligger svar, så jeg kan ferdelle pointene..!

men, med din metode craig.. der ville jeg jo også kunne lave semaphore (lock)
""Kommentar: md_craig
27/05-2006 00:06:46    Sagen er dog at du så skal tænke dig godt om når du gør det...""
og du var jo også selv inde på det samme-!
går ihvertfald udfra at det var det du ville gøre mig opmærksom på)

docs på Suspend/Resume opfordrer jo ikke ligefrem til at at bruge dem til thread synkronisering:

Do not use the Suspend and Resume methods to synchronize the activities of threads. You have no way of knowing what code a thread is executing when you suspend it. If you suspend a thread while it holds locks during a security permission evaluation, other threads in the AppDomain might be blocked. If you suspend a thread while it is executing a class constructor, other threads in the AppDomain that attempt to use that class are blocked. Deadlocks can occur very easily.

min kode skal nærmest ses som et svar på 00:06:46 "men ved ikke hvad den er blevet erstattet af"

selvom det faktisk også er i docs:

[ObsoleteAttribute("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", false)]
public void Suspend ()

og et svar

Hehe... jeps... desuden poster Arne_v nu lige præsis det jeg refererede til da jeg sagde at dokumentationen fortalte om komplikationerne og at man virkelig skulle tænke sig om...

Men jeg skal jo ikke være den der påstår at en person ikke godt kunne tænke sig så godt om ;)

Ang. "selvom det faktisk også er i docs:"

Jeg har tydeligvis ikke "Syntax" blokken åben i min dokumentation ^^ hehe... det kan jo ske :P...

takker for de ekstra info :)
nu vil jeg dog hoppe under dynen.. og kigge lidt kode imorgen..!

jep

det pudsige er iøvrigt at Java Thread suspend og resume docs har (og har haft siden
1998):

Deprecated. This method has been deprecated, as it is inherently deadlock-prone. If the target thread holds a lock on the monitor protecting a critical system resource when it is suspended, no thread can access this resource until the target thread is resumed. If the thread that would resume the target thread attempts to lock this monitor prior to calling resume, deadlock results. Such deadlocks typically manifest themselves as "frozen" processes.