Click here to Skip to main content
15,886,110 members
Home / Discussions / C#
   

C#

 
GeneralRe: Mulit-threading and function recursion with a form Pin
Kubajzz6-Sep-10 4:31
Kubajzz6-Sep-10 4:31 
GeneralRe: Mulit-threading and function recursion with a form Pin
fdsfsa76f7sa66-Sep-10 5:13
fdsfsa76f7sa66-Sep-10 5:13 
GeneralRe: Mulit-threading and function recursion with a form Pin
Pete O'Hanlon6-Sep-10 4:59
mvePete O'Hanlon6-Sep-10 4:59 
AnswerRe: Mulit-threading and function recursion with a form Pin
Cracked-Down6-Sep-10 8:21
Cracked-Down6-Sep-10 8:21 
AnswerDammit, stop blabbing and give him the code already... Pin
lepipele7-Sep-10 4:53
lepipele7-Sep-10 4:53 
GeneralRe: Dammit, stop blabbing and give him the code already... Pin
lepipele7-Sep-10 5:10
lepipele7-Sep-10 5:10 
GeneralRe: Dammit, stop blabbing and give him the code already... Pin
fdsfsa76f7sa69-Sep-10 1:27
fdsfsa76f7sa69-Sep-10 1:27 
GeneralRe: Dammit, stop blabbing and give him the code already... Pin
lepipele9-Sep-10 6:20
lepipele9-Sep-10 6:20 
Thread should be created in situations when you need to control the flow of the thread (although, as you also read Abort is not a good idea) and you are not creating bunch of threads at once. If you wish to see for yourself most "common sense" benchmark for this situation try following code:

private void benchmarkThread()
{
    Stopwatch sw = new Stopwatch();
    sw.Start();
    for (int i = 0; i < 1000; i++)
    {
        Thread t = new Thread(foo);
        t.Start();
    }

    sw.Stop();
    MessageBox.Show(sw.ElapsedMilliseconds.ToString());
}

private void benchmarkQueue()
{
    Stopwatch sw = new Stopwatch();
    sw.Start();
    for (int i = 0; i < 1000; i++)
    {
        ThreadPool.QueueUserWorkItem(new WaitCallback(foo));
    }

    sw.Stop();
    MessageBox.Show(sw.ElapsedMilliseconds.ToString());
}

private void foo(object o)
{

}

private void button2_Click(object sender, EventArgs e)
{
    benchmarkThread();
}

private void button3_Click(object sender, EventArgs e)
{
    benchmarkQueue();
}


In my case I get around 5000 ms for Threads and 23 ms for Queue... so winner is more than clear. The reason why this difference is so big is that there are bunch of things that need to be done just so you can get a Thread. And ThreadPool is nothing more than a Pool of Threads that are pre-created for your application context.

So - conclusion or why I have started telling all this - if you have pretty good design/understanding of your code and KNOW how many threads you'll be spawning (be sure to understand that things like Form.BeginInvoke also use ThreadPool!!)... and that number is less then a number of Threads pre-created in ThreadPool (default is 25 I believe; you can influence this number) - then definitely go with ThreadPool.

Recommendation you've read is there because in bigger teams/on bigger projects often people carelessly use ThreadPool. So, situations in which requests come faster than they are processed arise, and then you see large memory/CPU increase of your app; because if all 25 threads of ThreadPool are doing something new QueueUserWorkItem requests will be - of course - queued. If your application can eventually process all requests and recover, everything will be fine; however if requests come faster then they are processed for a long time - you are eventually in some serious trouble (if you can't resubmit requests, app will lose all of them when it eventually crashes because of OutOfMemory). Notice that using Threads manually in this situation isn't silver bullet - just you will probably run out of resources much more quickly / problem will be more obvious.

Finally, using Thread.Abort - I understand you. I'm the one that also holds reference to the thread and then fires Abort... who gives a damn when it works in most cases Wink | ;) . However, if you want to know on why it's not a good practice - go here[] (some of the explanations are really good).
QuestionRe: Dammit, stop blabbing and give him the code already... [modified] Pin
fdsfsa76f7sa69-Sep-10 22:37
fdsfsa76f7sa69-Sep-10 22:37 
AnswerRe: Dammit, stop blabbing and give him the code already... Pin
lepipele13-Sep-10 9:30
lepipele13-Sep-10 9:30 
GeneralRe: Dammit, stop blabbing and give him the code already... Pin
fdsfsa76f7sa67-Sep-10 5:24
fdsfsa76f7sa67-Sep-10 5:24 
QuestionWindows Task Scheduler problem Pin
Tridip Bhattacharjee6-Sep-10 1:45
professionalTridip Bhattacharjee6-Sep-10 1:45 
AnswerRe: Windows Task Scheduler problem Pin
Pete O'Hanlon6-Sep-10 2:12
mvePete O'Hanlon6-Sep-10 2:12 
GeneralBSCS FINAL PROJECT Pin
HUSSNAIN TOUFIQ6-Sep-10 0:53
HUSSNAIN TOUFIQ6-Sep-10 0:53 
GeneralRe: BSCS FINAL PROJECT PinPopular
OriginalGriff6-Sep-10 0:57
mveOriginalGriff6-Sep-10 0:57 
GeneralRe: BSCS FINAL PROJECT Pin
dan!sh 6-Sep-10 0:58
professional dan!sh 6-Sep-10 0:58 
GeneralRe: BSCS FINAL PROJECT Pin
Eddy Vluggen6-Sep-10 1:14
professionalEddy Vluggen6-Sep-10 1:14 
GeneralRe: BSCS FINAL PROJECT PinPopular
J4amieC6-Sep-10 1:28
J4amieC6-Sep-10 1:28 
GeneralRe: BSCS FINAL PROJECT Pin
DaveyM696-Sep-10 1:35
professionalDaveyM696-Sep-10 1:35 
GeneralRe: BSCS FINAL PROJECT Pin
Smithers-Jones6-Sep-10 2:12
Smithers-Jones6-Sep-10 2:12 
GeneralRe: BSCS FINAL PROJECT PinPopular
Pete O'Hanlon6-Sep-10 2:25
mvePete O'Hanlon6-Sep-10 2:25 
GeneralRe: BSCS FINAL PROJECT Pin
Smithers-Jones6-Sep-10 2:31
Smithers-Jones6-Sep-10 2:31 
GeneralRe: BSCS FINAL PROJECT Pin
Dave Kreskowiak6-Sep-10 3:52
mveDave Kreskowiak6-Sep-10 3:52 
Generalzoo Pin
Luc Pattyn6-Sep-10 5:15
sitebuilderLuc Pattyn6-Sep-10 5:15 
GeneralRe: BSCS FINAL PROJECT Pin
DaveyM696-Sep-10 2:38
professionalDaveyM696-Sep-10 2:38 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.