Threading best practices and some moderately complex examples

I am interested in using threads and want some best practices example. I know how to start and run a simple sub but I saw some examples where delegates were used and would like to know about some more than simple applications of threading. If you have used threads in situations where it worked out great would like to know about it (i know about the basic scenarios like keeping the UI responsive, but would like some feedback from someone who has used it for something more uncommon like using beginexecutereader to get datareader in a different thread, or to populate some control periodically, etc).

Thanks.
LVL 14
shahprabalAsked:
Who is Participating?
 
Mike TomlinsonConnect With a Mentor Middle School Assistant TeacherCommented:
Threading advice based on questions I've answered here on EE.  Some seem obvious but you'd be suprised how many questions are answered with these concepts...

(1) OBVIOUSLY...Don't update UI controls from a Thread without Delegates/Invoke...but you can "cheat" by setting the Control.CheckForIllegalCrossThreadCalls property.  You just need to know when it is safe to use the "cheat"...

(2) ALL GUI controls run in the same main UI thread...so you can use the form itself to test if an Invoke is required...such as "Me.InvokeRequired" instead of "Label1.InvokeRequired".

(3) Don't call Application.DoEvents() from a Thread.

(4) An infininte loop in a thread WILL prevent an app from exiting unless it has the Thread.IsBackground() property set to True.

(5) An infinite loop without some kind of "throttle" (or a blocking call in it) WILL ramp CPU usage to 100%.  Place a SMALL (less than 100) call to Thread.Sleep() to avoid this.

(6) Encapsulate threads in a class and pass parameters to the class.  This way you can have more than one instance of your "thread"...each with distinct parameters.  Raise events from the class to communicate back to your main form.

(7) You can create a "scheduled event" without a Timer by creating a new thread and putting it to sleep for the required amount of time.  Use (6) above to notify the main UI of the event.

(8) In general, it is a bad idea to call Thread.Abort() since this literally cuts off your threading code and doesn't allow it to clean up.  This can problems in ~some~ situations where you need to manually release memory or perform operations in some kind of "atomic" unit.  If this is the case, then create a boolean flag to toggle when a thread should exit on its own terms.  Check the flag often in your threading code.

(9) A thread "exits" and is "complete" when the code in it reaches the LAST line of code.

I'm probably forgetting something...I'll post more if I think of anything.
0
 
joechinaConnect With a Mentor Commented:
0
 
shahprabalAuthor Commented:
good article... meanwhile can someone share their experience and maybe some do and don't for threading...  something that I might not find in a book.
0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
shahprabalAuthor Commented:
Thanks Idle_Mind ... this was exactly what I wanted... pointers and dos dont from someone who has used threads in apps... is there anything that you are unfamiliar with ????????
0
 
Mike TomlinsonMiddle School Assistant TeacherCommented:
"is there anything that you are unfamiliar with ????????"

LOL...trust me...there is PLENTY in the programing world, even in VB.Net, that I have ABSOLUTELY no clue how to do!  =)
0
 
shahprabalAuthor Commented:
I doubt that.... Still thanks for making us feel like n00bs :)
0
 
shahprabalAuthor Commented:
Idle Mind, I am working on a multithreaded app and am populating a treeview control with the servers on the network in a seperate thread... even though the form loads while the control is being populated the ui is not responsive... to fix this I added Application.DoEvents in the loop that populates the control and the app behaves much better... according to ur list above calling Application.DoEvents is a no-no... can you elaborate on that...
0
 
Mike TomlinsonMiddle School Assistant TeacherCommented:
You're calling DoEvents() from within the Thread?  Or after you have used Delegates/Invoke to get back on the main UI thread?

The problems I've seen with DoEvents() from a different Thread were when it was being callled repeatedly in quick succession from a Timer or infinite loop in another thread.
0
 
shahprabalAuthor Commented:
Basically this is what I am trying to do :
http://www.experts-exchange.com/Programming/Languages/.NET/Visual_Basic.NET/Q_22494712.html

And I got the program to work both ways... i.e. using a background worker and without it...
First I tried without it... works as expected... but the UI is not responsive... when I put the DoEvents in the loop that populates the TreeView... the form UI responds better (not as good as I would have liked)...

So I looked at the background worker and implemented that solution thinking I can trigger the ProgressChanged event and have DoEvents inside the event... Also I thought since BackgroundWorker is a built in component it might work better with the UI... but triggering DoEvents through the event is not giving me the desired result...  

Also I tracked the CPU usage in both senarios... not even hitting 10%.... using Pentium D 3.00Ghz dual core cpu... any thoughts
0
All Courses

From novice to tech pro — start learning today.