Re: Windows Task Scheduler problem - C# Discussion Boards

First Prev Next

Re: Dammit, stop blabbing and give him the code already...

lepipele7-Sep-10 5:10

lepipele

7-Sep-10 5:10

If you want to eliminate _waiting field in ThreadingWrapper class you should probably use _are.WaitOne(int timeout) overload instead of if(_waiting).

However, first make sure that you understand what current code is doing... and then try eliminating _waiting as a practice.

Re: Dammit, stop blabbing and give him the code already...

fdsfsa76f7sa69-Sep-10 1:27

fdsfsa76f7sa6

9-Sep-10 1:27

I'm using my own thread now, because I've read that ThreadPool should be only used for short operations. I replaced the waiting flag with ThreadState, so I managed to eliminate _waiting. I set the thread's IsBackground property to true, so that it gets aborted on exit.

But I want to abort the thread early myself in certain situations and I've read that using Abort() method isn't a wise thing to do. The only other way that I can think of is to create a flag, which is checked after each function call. If true, the function will return. The function gets 52 calls deep at most, usually around 10 calls deep.
However, I don't know if this will really "destroy the thread", or will the thread just be stopped. Will creating a new ThreadingWrappper object (to the same variable) destroy the thread?

Thanks in advance!

Re: Dammit, stop blabbing and give him the code already...

lepipele9-Sep-10 6:20

lepipele

9-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).

Re: Dammit, stop blabbing and give him the code already... [modified]

fdsfsa76f7sa69-Sep-10 22:37

fdsfsa76f7sa6

9-Sep-10 22:37

Thanks, I think I understand ThreadPool a bit better now, but I still have some questions:

-Should I worry about the limit of 25 threads or will ThreadPool remove finished ones when the program queues 26th+ thread?
-Is there any safe way to abort/stop a thread from ThreadPool, such as with a flag within the function, so that it gets aborted at the right time?

I have 3 different functions to work on a separate thread, so I basically just need 3 different threads (not counting the STAThread and BeginInvoke threads). The functions can be launched any number of times though (but only one instance at the time), so the finished WorkItems should be removed if there's no way of reusing them.

Thanks in advance!

modified on Friday, September 10, 2010 4:59 AM

Re: Dammit, stop blabbing and give him the code already...

lepipele13-Sep-10 9:30

lepipele

13-Sep-10 9:30

You probably found answer by now, but:

1. Threads are automatically recycled when they finish performing work assigned to them (exit outside method)
2. Not as far as I know - you can't say from outside: "Hey, turn off Thread #23". But inside method you can look for certain switches/flags (class bool parameter for example) and have some condition like:

if (flag) 
    return; // exiting out of method

Re: Dammit, stop blabbing and give him the code already...

fdsfsa76f7sa67-Sep-10 5:24

fdsfsa76f7sa6

7-Sep-10 5:24

Thanks, that's great. Heading to MSDN now to get some understanding about ThreadPool.QueueUserWorkItem and WaitCallBack... Thanks again!

Windows Task Scheduler problem

Tridip Bhattacharjee6-Sep-10 1:45

Tridip Bhattacharjee

6-Sep-10 1:45

i just configure win task scheduler in one server that it will run a exe file at specific time but the problem is win task scheduler invoking the exe file many times. suppose when someone connect to that machine over the vpn & remote desktop then suddenly win task scheduler calling that exe. so as many time a user is connecting that server over the vpn some time that exe is calling by win task scheduler. so i just could not understand this behavior of win task scheduler.
so please tell me how to prevent win task scheduler to call exe before the setting time if many user connect to that server over the vpn. i need solution......very urgent.

thanks in advance.

tbhattacharjee

Re: Windows Task Scheduler problem

Pete O'Hanlon6-Sep-10 2:12

Pete O'Hanlon

6-Sep-10 2:12

Tridip Bhattacharjee wrote:
so please tell me how to prevent win task scheduler to call exe before the setting time if many user connect to that server over the vpn.

This has absolutely nothing to do with C#. Try posting this in the infrastructure[^] forum.

I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Onyx

BSCS FINAL PROJECT

HUSSNAIN TOUFIQ6-Sep-10 0:53

HUSSNAIN TOUFIQ

6-Sep-10 0:53

I AM STUDENT OF BSCS AND MY FINAL PROJECT IS NOW STARTED. MY FINAL PROJECT IS ABOUT ICMP CONTROLLING SYSTEM.PLZ HELP ME ABOUT THIS PROJECT.
TAHNXXXXXXXXXX