useful multithreading tutorial

[Anti-Rich]

hey all,

i have recently started multi-threading my applications. i was looking for a more in depth tutorial about multi-threading, as the inital tutorial i found was lacking in the really in depth stuff (which i know im going to need eventually). so i came across this, which is from a book "Professional VB.NET 2nd Edition", which is extremely good and covers quite a bit of the theory behind multi-threading, as well as (what i think) is a really good way of implementing it in an application.

so enjoy, and if anyone knows of other tutorials, by all means please post them as i would like to know all the information i possibly can, before i start implementing it in a project for my employer.

http://www.stardeveloper.com/articles/display.html?article=2002110404&page=1

have a good one

regards
adam

 

[jmcilhinney]

The main issue with that tutorial is that it doesn't include the BackgroundWorker component, which is new in 2005. Other than that it looks pretty good. I'd also suggest reading the MSDN section on managed threading, particularly when you're a bit more comfortable with the concepts.

http://msdn2.microsoft.com/en-US/library/3e8s7xdd.aspx

 

[Anti-Rich]

hey jmc

thanks for your feedback. i have heard of the backgroundworker, would that usually be used for data access work? in my application i aim to have two threads, the main application thread and another thread running which handles any data access/manipulation and sends the relevant information back to the main thread (via delegate) to alter the UI. since i am using 2005, does this mean i simply need to use the "BackgroundWorker" thread?

like i said, im new to this and still trying to get my head around the general theory and implementation of multithreading

cheers
adam

 

[jmcilhinney]

One of the difficulties in using worker threads is notifying the UI of things that happen during the execution of the worker or when the worker ends. The BackgroundWorker hides this complexity by raising its ProgressChanged and RunWorkerComplete events in the UI thread. The RunWorkerComplete event is ALWAYS raised whenever a BackgroundWorker completes its task, so if you notify the UI that the task is complete you simply handle the RunWorkerComplete event. There's no need for you to worry about which thread code is being executed on. Similarly if you call the ReportProgress method it will raise the ProgressChanged event in the UI thread, so you can update the UI without having to worry about which thread your code is being executed on. If you use Thread objects directly then you have to use delegation to cross the thread boundary to update the UI on the appropriate thread. That's why the BackgroundWorker exists.

 

[Anti-Rich]

hm, so are you saying that if i choose to use the backgroundworker thread, i dont need to worry about delegates to update my ui? i simply need to handle an event (from the ui thread) in regards to the work being complete in the backgroundworker thread.

im a little confused, and it seems to me that using delegates (although a slightly more complex way) is a more flexible way of communicating changes, as i can create several delegates to handle several different situations. where as if i simply handle the runworkercomplete event, it only allows room for one outcome.

cheers for your input

regard
adam

 

[jmcilhinney]

There's always a trade-off between complexity and power. If you want more power then you usually have to endure more complexity. The BackgroundWorker isn't a panacea. It isn't going to be appropriate in all situations and it's not intended for all situations. It is intended to make implementing simple scenarios easier. If you have a complex scenario then explicit threading is a better idea.

Having said that, every thread only ends once so why would you want to invoke multiple delegates as an alternative to handling the RunWorkerComplete event? If you want to execute multiple methods when the worker completes you simply call multiple methods from the RunWorkerComplete event handler. It's invoking multiple delegates during the life of the worker that's more of an issue. The ProgressChanged event is primarily intended to allow you to update the UI to reflect the progress of the worker, but it also allows you to pass an Object parameter. This can be used to make decisions as to how to proceed from the event handler. Again, that's OK for simple scenarios but for situations of any reasonable complexity explicit threading and delegation is a better option.

In short, explicit threading is definitely more powerful and more flexible but in the very large number of cases where that power and flexibility is not required it is preferable to go with the simplcity of the BackgroundWorker.

 

[Anti-Rich]

ok my situation is this.

say i have a ui thread and a data access thread running in the background.

from the ui thread i call the data access thread and ask it to return a list of values to populate a combo box... the dat(data access thread) does this and through a delegate populates the combobox with the required values.

next, the ui thread calls the dat and asks it to return another list of values, this time, however, it will go to a listview. the dat does this and through a delegate specifically designed to handle the listview (just like the first one was designed to handle the combo box), populates the listview.

and so on and so forth.

this is why i think it would be better to use delegates, or am i missing something? your feedback has been greatly appreciated.

regards
adam

 

[jmcilhinney]

You must be creating more than one worker thread in that scenario, or as far as I can tell you should be. That just means that if you want to use the BackgroundWorker class you'd create more than one instance. Each instance would have a different method handling its RunWorkerComplete event. I'm not saying that you have to use a BackgroundWorker, or even that you should. I'm saying that they exist for a reason and if your situation suits their use then you can chose to use one or more than one as needed.

 

[Anti-Rich]

hm, its something i need to think on. i think i might stick with explicit threading. you stated that it was powerful but unnecessarily complex for some situations... the benefit of doing it explicitly for any situation, is later on, if i need to thread a complex situation i already have a very good idea of how to do it.

thanks for your input though, it has been greatly appreciated

have a good one
regards
adam

EDIT: in addition to this, i enjoy having full control and full flexibility over what im coding. which is why i prefer doing a way where i have much more flexibility and control