Form Multithreading in C#

Senotaru said:

Derpin' pretty hard there Monrox? I have no idea why you would suggest using multiple listboxes. There is several ways you can do this. With a background list, dictionary, or even a queue, that is being checked for items to add on the main thread.

You can also use .invoke or .begininvoke like people have already suggested. You won't get exceptions running on this model.

I'm seriously perplexed in what situation you would use 10 listboxes to cover multithreading. That seems redundant and arbitrary.

Click to expand...

Monrox said:

Your 'suggested' several ways are effectively diminishing the value of using multiple threads. Do you actually understand how threads work? Almost ANYTHING shared between threads SHOULD be LOCKED when a thread is accessing it, esp. if changes are to be made.

Otherwise we may allow for changes that will confuse the runtime. MS explicitly states that a multithreaded access to a shared object is not under the control of a regular developer. Like for example adding something to a dictionary; it may happen that a thread is adding a value up to the 5th byte, then another thread jumps in, drops 3 bytes of its value than the first thread comes back and pots the remaining stuff... you end up with gibberish. All such classes (or object instantiated thereof) are marked as thread unsafe in MSDN.

At least you know that this can be avoided with invoke etc, heck you can even disregard the danger by disabling cross thread warnings and pray nothing goes wrong.

The big BUT: when you go crazy on the locking, you are crippling the application speedwise. If the threads are finishing fast and thus need to constantly access the said dicitionary, it will result in a bottleneck. While a thread is doing its stuff there, all others will have to wait in line doing nada. Even worse, if a thread hangs, the whole application will lock hard. Of course you can say that a good developer should account for every worst case scenario but seeing how even hugely tested and retested programs like IE, FF and Chrome still lock from puny badly coded webpages it really is unfeasible.

The real power of multithreading is their independence and you want to tie them to a single resource (quote: a background list, dictionary, or even a queue). In my previous post I mentioned using text files to avoid such blocking bottlenecks. The harddrive is slow so yeah, that is not the best way to gain speed but then again you can use ram storage to offset that. Just didn't want to make the simple principles overcomplicated with an accompanying fluff.

Assuming you are interested to know how would I get the best speed in scraping: I would get a list of 1 million urls, split it into 1000 entries, create 1000 threads, assign each smaller list to a thread then start the threads making them save the results in some container of their own. When a thread has finished all the fetching, it will be allowed to unload its stuff into a global shared container. Yes locking it, but only once per thread during the whole execution process.

You on the other hand can go with a shared list, fetch urls one by one then update the global container, again one entry at a time, and when you are finally done in a week or so, come back and post whether you're still perplexed why using dedicated resources is better than using shared ones.

Click to expand...

http://msdn.microsoft.com/en-us/library/x13ttww7%28v=vs.71%29.aspx
http://msdn.microsoft.com/en-us/library/aa645755%28v=vs.71%29.aspx

Monrox said:

multithreaded posting

Click to expand...

gainer said:

I've only done multi-threading in c++. It shouldn't be much different spawning a new thread in a form than in a console app. It really depends on what your trying to do. Keep in mind when you spawn a new thread its like firing up a new program. You can do this in your main function the default name is Program.cs this is the file that fires up the forms. Also your talking about something simple with a listbox if you want the thread to modify the listbox your listbox will need to be a global variable so the thread can have access to the variable. You should also be able to fire up thread from anywhere in application. I've never done multithreading in C# but the concept should be the same.

Here I'll give you some c++ code I wrote in my operating systems class. Look up the Dining Philosopher problem before you look at the code and it will give you a good understanding of how threads work.

Code:

//Matthew ****
//CSC 306
//Dining Philosophers

#include <iostream>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <pthread.h>

#define IN_USE = false;
#define AVAIL = true;

using namespace std;

void *eatRice(void *phil);

//Chopsticks
bool cs[5];
int leftCS;
int rightCS;

void init(){
    for(int i=0; i<5; i++){
        cs[i] = true;
    }
}

int main(){

    init();

    pthread_t phils[5];
    int tid;
    for(int i=1; i<5; i++){
        tid = pthread_create(&phils[i], NULL, eatRice, (void *)i);
    }
    eatRice(0);
    tid = pthread_join(phils[1], NULL);

    return 0;
}

void *eatRice(void *phil){

    if(phil == 0){leftCS = 4;}
    else{leftCS = (long)phil-1;}
    rightCS = (long)phil;    

    int ate = 4;
    while(ate != 0){
        if(cs[rightCS] == true && cs[leftCS] == true){
            cs[rightCS] = false;
            cs[leftCS] = false;
            cout << "Philosopher " << (long)phil << " started eating." << endl;    
            cout << "Philosopher " << (long)phil << " finished eating." << endl;    
            for(int i = 1; i < random()%0xffffff; i++){}
            cs[rightCS] = true;
            cs[leftCS] = true;
            ate--;
        }
        else{
            for(int i = 1; i < random()%0xffff; i++){}
        }
    }
    pthread_exit(NULL);
}

Click to expand...

Monrox said:

Your 'suggested' several ways are effectively diminishing the value of using multiple threads. Do you actually understand how threads work? Almost ANYTHING shared between threads SHOULD be LOCKED when a thread is accessing it, esp. if changes are to be made.

Otherwise we may allow for changes that will confuse the runtime. MS explicitly states that a multithreaded access to a shared object is not under the control of a regular developer. Like for example adding something to a dictionary; it may happen that a thread is adding a value up to the 5th byte, then another thread jumps in, drops 3 bytes of its value than the first thread comes back and pots the remaining stuff... you end up with gibberish. All such classes (or object instantiated thereof) are marked as thread unsafe in MSDN.

At least you know that this can be avoided with invoke etc, heck you can even disregard the danger by disabling cross thread warnings and pray nothing goes wrong.

The big BUT: when you go crazy on the locking, you are crippling the application speedwise. If the threads are finishing fast and thus need to constantly access the said dicitionary, it will result in a bottleneck. While a thread is doing its stuff there, all others will have to wait in line doing nada. Even worse, if a thread hangs, the whole application will lock hard. Of course you can say that a good developer should account for every worst case scenario but seeing how even hugely tested and retested programs like IE, FF and Chrome still lock from puny badly coded webpages it really is unfeasible.

The real power of multithreading is their independence and you want to tie them to a single resource (quote: a background list, dictionary, or even a queue). In my previous post I mentioned using text files to avoid such blocking bottlenecks. The harddrive is slow so yeah, that is not the best way to gain speed but then again you can use ram storage to offset that. Just didn't want to make the simple principles overcomplicated with an accompanying fluff.

Assuming you are interested to know how would I get the best speed in scraping: I would get a list of 1 million urls, split it into 1000 entries, create 1000 threads, assign each smaller list to a thread then start the threads making them save the results in some container of their own. When a thread has finished all the fetching, it will be allowed to unload its stuff into a global shared container. Yes locking it, but only once per thread during the whole execution process.

You on the other hand can go with a shared list, fetch urls one by one then update the global container, again one entry at a time, and when you are finally done in a week or so, come back and post whether you're still perplexed why using dedicated resources is better than using shared ones.

Click to expand...