Tracking down threading issues in CF

  • Thread starter Thread starter Daniel Root
  • Start date Start date
D

Daniel Root

I am writing a multi-threaded application using the CF and have a basic
threading question:

I read in the CF Core reference that it's not a good idea to update
instance members of a class from a threaded proccess, but am unclear how
this applies, and how to safely update instance members without the
consuming class having to "know" about mutexes and the like...

For example, is the following pseudocode "bad":

class GPSManager
{
private float _Lat;
private float _Long;
public float Lat; //property to expose _Lat. get code left off..
public float Long;
private PollGPSCallback(object state)
{
//read GPS...
_Lat = gpsreader.GetLat();
_Long = gpsreader.GetLong();
//raise event
}
private tmr;
public Start()
{
// create callback delegate...
tmr=new System.Threading.Timer(cbPollGPS,null,0,5000);
}
public Stop()
{//stop timer, clear resources...}
....
}

The idea being that the consuming class can create an instance of
GPSManager, call Start(), and access the properties as needed...
In my testing, I haven't run into any issues accessing the properties
(Lat and Long) from the main thread, but am a bit nervous I could be
missing something. Is there something I should be doing to lock the code
within GPSCallback and/or in the properties' "get" code?

Thanks in advance!
Daniel Root
 
Daniel,

The main threading error people tend to make is trying to directly update a
control on a form from a different thread from the one the form was created on.
Usually apps crash pretty quickly, but it doesn't appear from your pseudocode
that you are doing that. If you have reason to believe that more than one thread
could be in a method at the same time, however, you can use the "lock" keyword
to serialize access to a method, similar to using critical sections in Win32
programming.
 
Back
Top