R
Ray Ackley
I'm experiencing a threading problem that's really perplexing me. I
have a multithreaded application that reads car ECU information that's
sent over the serial port by the ECU and received by the
laptop/program.
I'll try to give a concise synopsis as the program is easily 10k+
lines.
main.cs - contains the application start function. Here's the entire
code (minus misc junk) as it's rather small -
public class main
{
public static UIForm UI;
public static Reader terminal;
[STAThread]
public static void Main()
{
terminal = new Reader();
testform = new UIForm();
System.Windows.Forms.Application.Run(UI);
}
}
Nothing terribly complex here. UI is the user interface the user
interacts with.
Reader is the communications class. It does all the com port stuff as
well as processing and making sense of the data that's coming in.
When it opens a com port it spawns a new process that does the
low-level junk of monitoring the com port and stuffing incoming bytes
into a shared queue. Everything works A-OK in this department.
There is a "second level" reader function that takes those raw bytes,
dequeues them and handles synchronization and stuffing those bytes
into correctly-formed 16 byte arrays (ECU "packets") that the program
needs to decode. It's a big while loop that keeps repeating and doing
whatever it needs to do to the incoming bytes to massage them into the
correct packet formation. This function is spawned off as a separate
process and runs until the app is terminated. It is spawned off in
the constructor of the Reader class. Specifically:
public Reader()
{
settings = new CommReaderSettings(); // Just com port stuff
rxThreadLvl2 = new Thread(new ThreadStart(this.readLevel2));
rxThreadLvl2.Name = "RxLvl2";
rxThreadLvl2.Priority = ThreadPriority.Normal;
rxThreadLvl2.Start();
}
Now the rest of the reader class contains a bunch of different
functions that do different stuff but basically boil down to three
things - write data out the com port, write info the to UI, and
communicates with the RxLvl2 thread by reading and writing variables
in a SyncMe object.
Here's a snippet of the SyncMe class:
public class SyncMe
{
public bool ack=false;
public bool nak=false;
public bool Synced=false;
public bool lookingForVal=false;
public bool valFound=false;
public bool acknakFound=false;
}
Nothing too sexy there. The SyncMe class is declared as a non-static
object within the statically created (in main.cs) Reader
class/terminal object.
public class Reader
{
public SyncMe syncObj = new SyncMe();
public Reader() {...}
public void readLevel2() {...}
public void StopLogging() {...}
}
Now for my problem. I send a command to the ECU to stop sending data
and my problem occurs when trying to clear out the com port queue.
Obviously I can clear out the queue in software, but there are
invariably some bytes either in the out buffer of the ECU or in the in
buffer of the laptop. So I get anywhere from 0-20 bytes coming
through after I send the command to the ECU to stop sending data.
My strategy for this was simple - declare a boolean in the SyncMe
class that indicates that the readLevel2() function should continue to
receive bytes but simply throw them away. This boolean is flagged via
the UI calling a "Stop Logging" function in the Reader object which in
turn actually sets the bool.
If the readLevel2() function/loop sees a byte and has to throw it
away, it flags in the SyncMe obj that it has found one.
Here is the stop logging function:
public void StopLogging()
{
lock(typeof(SyncMe))
{
syncObj.clearQueue=true;
syncObj.logging=false;
syncObj.byteFound=false;
}
Thread.Sleep(1000);
if(syncObj.byteFound==true)
{
lock(typeof(SyncMe))
{ syncObj.byteFound=false; }
Thread.Sleep(1000);
}
}
However, the readLevel2() thread never completely throws away the
data. I've debugged and can see that it properly enters the code
block when the bools are flagged, so everything is fine there.
My suspicion is that when I tell the static Reader class (static
terminal object) to sleep it's also causing the readLevel2() thread to
sleep. This would mean that the readLevel(2) would have nearly zero
time to do any throwing away of bytes.
I don't know why or how, but it's the only explanation I can think of.
Does this make any sense at all? I know it "shouldn't" be happening,
but none of the MSDN samples or other threading samples I have scoured
the web for give ANY examples of spawning/sleeping/etc with static
objects.
Is this sleep call indeed sleeping both threads? If you can't tell
from the code and description, is there some way I can determine this
myself?
Thanks,
Ray Ackley
have a multithreaded application that reads car ECU information that's
sent over the serial port by the ECU and received by the
laptop/program.
I'll try to give a concise synopsis as the program is easily 10k+
lines.
main.cs - contains the application start function. Here's the entire
code (minus misc junk) as it's rather small -
public class main
{
public static UIForm UI;
public static Reader terminal;
[STAThread]
public static void Main()
{
terminal = new Reader();
testform = new UIForm();
System.Windows.Forms.Application.Run(UI);
}
}
Nothing terribly complex here. UI is the user interface the user
interacts with.
Reader is the communications class. It does all the com port stuff as
well as processing and making sense of the data that's coming in.
When it opens a com port it spawns a new process that does the
low-level junk of monitoring the com port and stuffing incoming bytes
into a shared queue. Everything works A-OK in this department.
There is a "second level" reader function that takes those raw bytes,
dequeues them and handles synchronization and stuffing those bytes
into correctly-formed 16 byte arrays (ECU "packets") that the program
needs to decode. It's a big while loop that keeps repeating and doing
whatever it needs to do to the incoming bytes to massage them into the
correct packet formation. This function is spawned off as a separate
process and runs until the app is terminated. It is spawned off in
the constructor of the Reader class. Specifically:
public Reader()
{
settings = new CommReaderSettings(); // Just com port stuff
rxThreadLvl2 = new Thread(new ThreadStart(this.readLevel2));
rxThreadLvl2.Name = "RxLvl2";
rxThreadLvl2.Priority = ThreadPriority.Normal;
rxThreadLvl2.Start();
}
Now the rest of the reader class contains a bunch of different
functions that do different stuff but basically boil down to three
things - write data out the com port, write info the to UI, and
communicates with the RxLvl2 thread by reading and writing variables
in a SyncMe object.
Here's a snippet of the SyncMe class:
public class SyncMe
{
public bool ack=false;
public bool nak=false;
public bool Synced=false;
public bool lookingForVal=false;
public bool valFound=false;
public bool acknakFound=false;
}
Nothing too sexy there. The SyncMe class is declared as a non-static
object within the statically created (in main.cs) Reader
class/terminal object.
public class Reader
{
public SyncMe syncObj = new SyncMe();
public Reader() {...}
public void readLevel2() {...}
public void StopLogging() {...}
}
Now for my problem. I send a command to the ECU to stop sending data
and my problem occurs when trying to clear out the com port queue.
Obviously I can clear out the queue in software, but there are
invariably some bytes either in the out buffer of the ECU or in the in
buffer of the laptop. So I get anywhere from 0-20 bytes coming
through after I send the command to the ECU to stop sending data.
My strategy for this was simple - declare a boolean in the SyncMe
class that indicates that the readLevel2() function should continue to
receive bytes but simply throw them away. This boolean is flagged via
the UI calling a "Stop Logging" function in the Reader object which in
turn actually sets the bool.
If the readLevel2() function/loop sees a byte and has to throw it
away, it flags in the SyncMe obj that it has found one.
Here is the stop logging function:
public void StopLogging()
{
lock(typeof(SyncMe))
{
syncObj.clearQueue=true;
syncObj.logging=false;
syncObj.byteFound=false;
}
Thread.Sleep(1000);
if(syncObj.byteFound==true)
{
lock(typeof(SyncMe))
{ syncObj.byteFound=false; }
Thread.Sleep(1000);
}
}
However, the readLevel2() thread never completely throws away the
data. I've debugged and can see that it properly enters the code
block when the bools are flagged, so everything is fine there.
My suspicion is that when I tell the static Reader class (static
terminal object) to sleep it's also causing the readLevel2() thread to
sleep. This would mean that the readLevel(2) would have nearly zero
time to do any throwing away of bytes.
I don't know why or how, but it's the only explanation I can think of.
Does this make any sense at all? I know it "shouldn't" be happening,
but none of the MSDN samples or other threading samples I have scoured
the web for give ANY examples of spawning/sleeping/etc with static
objects.
Is this sleep call indeed sleeping both threads? If you can't tell
from the code and description, is there some way I can determine this
myself?
Thanks,
Ray Ackley