Read/Write from another Thread

[to_sam]

I have to implement a trace window in my application. So I have a List (System.Collections.List<>) which serves as a buffer and a grid control which serves as trace output. As items are being added to the buffer list, I want to update my grid with the newly arrived data. So I thought of creating a thread that polls the list. This is the method to add elements:


List<TraceRow> _detectedResults;
public void AddToList(TraceRow row)
{
lock (_detectedResults)
{
_detectedResults.Add(row);
}
}


The thread:


Thread readFromListThread = new Thread(ReadDataFromList);
readFromListThread.Start();


and the polling:


static void ReadDataFromList()
{
while(true)
{
lock(_detectedResults)
{
foreach (TraceRow traceRow in _detectedResults)
{
FillGridControl(traceRow);
}
}
}
}


The problem is, this is very slow and eats too much of the resources. Also I have a feeling that there is another way to do this...any suggestions?

[torrud]

Use events.

Well, you can create a collection class which contains all entries like you described. Then you put an changed event into the collection. Every time an entry is added to the list the changed event will be thrown.
Register an eventhandler on your GUI to the collection and refresh the GUI if the event is thrown. Should be easy to implement and you need no stupid blocking threads.

[DeepT]

Do what torrud said. I just want to underscore the idea that "polling" is bad, and "pushing" is good. To be clear, ill give an example of polling vs pushing.

Alpha wants to know if Beta has some new data:

Polling: Non-Event driven design (bad)

Alpha calls Beta every N seconds to see if Beta has new data. Alpha does a lot of wasted work because Beta frequently does not have new data.

Pushing: Event Driven design (good)

Alpha subscribes to a NewData event on Beta.
Beta does its thing and whenver new data appears, it invokes the event handler NewData. This does not do any unecessairy work

[jmcilhinney]

Use events.

Well, you can create a collection class which contains all entries like you described. Then you put an changed event into the collection. Every time an entry is added to the list the changed event will be thrown.
Register an eventhandler on your GUI to the collection and refresh the GUI if the event is thrown. Should be easy to implement and you need no stupid blocking threads.The key to this is delegation. This suggestion is useless without it because the event will be raised on the worker thread so accessing any UI elements, i.e. controls, from the event handler will throw an exception. Use a BackgroundWorker if it's appropriate or else implement your own delegation.

http://www.vbforums.com/showthread.php?t=471889
http://www.vbforums.com/showthread.php?t=498387

[Mutant_Fruit]

It wonn't throw an exception if you do it right. How else do you think people do asynchronous work other than using separate threads?

In your event handler you just have to check if you need to switch to the main thread to modify the control. Read here for more info: http://msdn2.microsoft.com/en-us/library/zyzhdc6b.aspx

[Rudegar]

and use "InvokeRequired" is a good idea if other threads access guiElements in another

[jmcilhinney]

Am I being punk'd here? Using the InvokeRequired property and the Invoke method IS using delegation, which is exactly what I said needed to be done. The InvokeRequired property tells you whether delegation, i.e. marshalling to the control's owning thread, is needed. If it is you create a delegate and pass that to the Invoke method, which marshals the call to the owning thread and invokes the delegate, which then invokes the method it refers to. If you follow the second link in post #4 you'll find my detailed explanation of how and why to do it.

[Mutant_Fruit]

I think i just misunderstood what you were saying. I thought you were saying that if you used a special thread to process the data, it would result in an exception being thrown. My bad!