threading question

[Analizer1]

is there a alternative to doevents() for threads

In my Case there is no UI


does thread.sleep() yield to windows or just stop the current thread for the
time

tks

 

[Andy]

is there a alternative to doevents() for threads

In my Case there is no UI

does thread.sleep() yield to windows or just stop the current thread for the
time

tks

I think it just stop the current thread. If your application has no
UI, what do you need to yield to?

 

[Jon Skeet [C# MVP]]

is there a alternative to doevents() for threads

In my Case there is no UI

In that case you need to work out what you actually want to achieve.
What's your actual goal here?

does thread.sleep() yield to windows or just stop the current thread for the
time

Well, both. It isn't a spinlock, if that's what you were wondering.

 

[Brian Gideon]

is there a alternative to doevents() for threads

In my Case there is no UI

does thread.sleep() yield to windows or just stop the current thread for the
time

tks

I'm confused. If there is no UI then there is no message loop and
thus no concept of a DoEvents to begin with. Can you be a little more
specific about what you're trying to do?

 

[Peter Duniho]

is there a alternative to doevents() for threads

In my Case there is no UI

Even if you had a UI, calling DoEvents() is a bad thing to do.

does thread.sleep() yield to windows or just stop the current thread for
the
time

As others have said, you should be more specific as to what you want to
do. Calling Sleep() does in fact cause the thread to yield. But there
are usually much better ways to manage that. Thread.Sleep() isn't nearly
as bad as Application.DoEvents(), but it's still overused.

Pete

 

[Ben Voigt [C++ MVP]]

is there a alternative to doevents() for threads

In my Case there is no UI


does thread.sleep() yield to windows or just stop the current thread for
the time

Sleep(0) cancels the rest of your timeslice so other runnable threads (of
equal or higher priority) will run. If no such threads exist your thread
will resume immediately.

Sleep(N) where N>0 cancels the rest of your timeslice and also marks your
thread not runnable for N milliseconds, which lets Windows run low priority
threads or idle the CPU for power saving.

 

[amdrit]

I think the OP was thinking in the ways of VB6--, that is, if you have a
long running loop, free the processor for other applications to have a whack
at it. Message loops weren't the only reason you used doevents.

Ben's post was right on I think in response. When you have a long running
process play nice with the other processes around you. Either go off the
radar long enough for others to have a whack (Sleep(0)), or sit there
quietly for a while and wait (Sleep(n)).

 

[Analizer1]

I have Background processes running...3 threads
most are short..
there kicking off StoredProcedures and doing some
record set processing , creating output files

so i want to give the OS some time to do other things
instead of kicking off these thread back to back acync
they run 24/7 as back end server processing
I dont want to put them to sleep for very long
but if a user is on the server doing things...

Dont want the user sitting there waiting for windows to respond

thanks for all your responses

 

[Jon Skeet [C# MVP]]

I have Background processes running...3 threads
most are short..
there kicking off StoredProcedures and doing some
record set processing , creating output files

so i want to give the OS some time to do other things
instead of kicking off these thread back to back acync
they run 24/7 as back end server processing
I dont want to put them to sleep for very long
but if a user is on the server doing things...

Dont want the user sitting there waiting for windows to respond

In that case just set them as lower priority threads. That's better
than just periodically sleeping.

 

[amdrit]

Jon help me learn something new here. I am not understanding your
alternative or perhaps your reservations with sleeping a thread.

say I have a worker process processing in a loop

do
{

// work code here

//Now let someone else talk to the processor
Thread.sleep(0)

} loop while (notdone == true)

How does setting the thread priority ensure that the work gets completed and
allows other processes to process? Isn't that one reason sleep was made
for? I come from VB where we were told to DoEvents everywhere, where VB
wasn't "threadable". Now that we are in a "threaded" environment we are
told not to thread and asked to refrain from sharing with the other
processes, what am I missing?

 

[Jon Skeet [C# MVP]]

Jon help me learn something new here. I am not understanding your
alternative or perhaps your reservations with sleeping a thread.

say I have a worker process processing in a loop

do
{

// work code here

//Now let someone else talk to the processor
Thread.sleep(0)

} loop while (notdone == true)

How does setting the thread priority ensure that the work gets completed and
allows other processes to process? Isn't that one reason sleep was made
for? I come from VB where we were told to DoEvents everywhere, where VB
wasn't "threadable". Now that we are in a "threaded" environment we are
told not to thread and asked to refrain from sharing with the other
processes, what am I missing?

By setting the thread priority relatively low, you're saying "anything
important (like the UI) should have more processor time than me".
Threads don't hog the processor for very long at a time anyway - but
setting the priority lower gives a hint that you don't mind receiving
less processor time than other threads. You'll still be sharing time
with other threads, whatever you do.

DoEvents() specifically dealt with the fact that you wanted to get
other events processed on the *same* thread - that's a very different
deal.

 

[Willy Denoyette [MVP]]

I have Background processes running...3 threads
most are short..
there kicking off StoredProcedures and doing some
record set processing , creating output files

so i want to give the OS some time to do other things
instead of kicking off these thread back to back acync
they run 24/7 as back end server processing
I dont want to put them to sleep for very long
but if a user is on the server doing things...

Did you actually measured the CPU occupation of your process. It's hard to
believe that this process is CPU bound, other threads in the system should
have sufficient time to run while your threads are waiting for the SP to
return and while you are writing to the output files.

Dont want the user sitting there waiting for windows to respond

If your process is CPU bound you can try by running at a lower priority, or,
just limit the number of threads to 1 or 2.

Willy.

 

[Analizer1]

all your responses have been very helpful

I'll prob set the priority lower, since these are worker threads that run
non stop

thanks again very much appriciated

 

[Rene]

I would just let the "Timer" object handle this. I really doubt that you
could create a more efficient way of handling idle time than using the Timer
object.. but maybe I am wrong.

You can set the Timer to fire every 5 seconds, 10 seconds, 5 minutes etc.

Check out the "System.Timers.Timer" object.

 

[Analizer1]

these threads at any given Time may have 1000 jobs to do
the timers kick of the jobs when there are jobs to be done
if there are alot of jobs to do..i wanted to yield to windows in between
jobs....

The timer takes over when all jobs complete

there mite be 100 to 2500 jobs at a time to do
so i could not use a timer on each job (ie sleep 1 or 2 seconds) id lose lot
of work time and not get all jobs complete..

thanks
below is a small example of the method that the timer does call

TotalIds = GetIdCountReadyForProcessing() // gets a count of number of
incomming transactions

while (TotalIds > 0)
{


//if stopping service

if (this._StopRunning == true) { break; }

//here is where i put the sleep or i will change priority to a lower
Priority

Thread.Sleep(0)

//if there is a user interface running ie not serivice

for (int x = 0; x < this._aWorkers.GetLength(0); x++)

{

ThreadId = this._aWorkers[x].ThreadId;

if (this._aWorkers[x].IsBusy == false && this._aWorkers[x].Completed == true
&& this._aWorkers[x].CancellationPending == false)

{

if ((TmpId = this._FileInfo.GetNextInCommingId() > 0)

{

this._aWorkers[x].RunWorkerAsync(TmpId);

TotalIds--;

}

}

} // end of For loop

} // end of While

// re enables the timer

 

[Michael D. Ober]

Jon help me learn something new here. I am not understanding your
alternative or perhaps your reservations with sleeping a thread.

say I have a worker process processing in a loop

do
{

// work code here

//Now let someone else talk to the processor
Thread.sleep(0)

} loop while (notdone == true)

How does setting the thread priority ensure that the work gets completed
and allows other processes to process? Isn't that one reason sleep was
made for? I come from VB where we were told to DoEvents everywhere, where
VB wasn't "threadable". Now that we are in a "threaded" environment we
are told not to thread and asked to refrain from sharing with the other
processes, what am I missing?

In VB 6, the processing in your app almost always occurs on the same OS
thread as the user interface. When you see a program report "Not
Responding", what has happened is that the user interface OS thread has
gotten busy and is not checking the message queue. The DoEvents() call is
how a Windows GUI application can handle new messages and keep its
processing on the UI thread.

Note that console apps very rarely show "Not Responding" because the
Win32/64 console subsystem puts a layer between the application's input
queue and the underlying windows message queue.

In dotNet 2.0 - the basic Windows Form application has the same performance
issues as a VB 6 application. A dotNet Console application (and VB 6 apps
that use the Windows Console API calls) become "native" console
applications. dotNet also provides direct access to the operating system
threads through the the System.Threading.Thread class and the
System.Component.BackgroundWorker class. In addition, the dotNET framework
creates a pool of threads designed for short lived tasks such as IO
completion and exposes them through the ThreadPool - that's a completely
different discussion, however.

The question becomes "when should I use threads?" The answer depends on two
primary conditions. First, do you have long, computation or non-UI io bound
tasks that don't require interaction with the user. In this context, long
is "human real-time", or longer than about one and a half to two seconds.
Next, are these long tasks relatively independent of each other. If not,
they may not be good candidates for multi-threading as inter-thread
synchronization and communications can become debugging nightmares and
performance bottlenecks. Assuming you decide to use System.Threading, you
need to remember that updating your UI from the thread requires some
synchronization because the underlying Windows API doesn't like cross thread
updates to the UI thread. Anytime a Window is updated, messages are
generated and the source data addresses for the messages must be guaranteed
to exist (and not change) until after the UI message is processed. For this
situation, use the System.Component.BackgroundWorker class as it provides a
defined interface for updating the UI. In either case, if your thread is
CPU intensive, take a look at System.Thread.Thread.Priority property, which
you can use on any thread to control the thread's processing priority. For
CPU intensive threads, you might want to have the following line near the
beginning of the thread "System.Threading.Thread.CurrentThread.Priority =
ThreadPriority.BelowNormal" to tell the OS that this thread is not to
interfere with other applications, or even the UI thread of your
application. If your thread does a lot of disk or network IO, don't worry
about setting the thread priority as anytime a thread is in a wait state for
IO operations, it's taken out of the list of processing threads until the IO
completes.

In your application, I suspect that some external event triggers the need
for the background processing. If you can capture that event in a class and
then pass that class to a procedure, take a look at the ThreadPool as it
queues task requests. This way you could actually eliminate the do forever
loop in your sample.

Mike.

 

[Michael D. Ober]

these threads at any given Time may have 1000 jobs to do
the timers kick of the jobs when there are jobs to be done
if there are alot of jobs to do..i wanted to yield to windows in between
jobs....

The timer takes over when all jobs complete

there mite be 100 to 2500 jobs at a time to do
so i could not use a timer on each job (ie sleep 1 or 2 seconds) id lose
lot of work time and not get all jobs complete..

thanks
below is a small example of the method that the timer does call

Consider replacing your loop with

foreach (transaction tran in IncomingTransactions()) {
ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadProc), tran);
}

static void ThreadProc(Object stateInfo) {
transaction tran = (transaction)stateInfo;
// Process tran.
}

Doing this will allow the framework to handle the backlog and you don't need
to deal with arrays, etc. No timers are needed, except maybe to start the
foreach loop. A better method would be to use a callback delegate to start
the foreach loop and then you would only start processing when there are
transactions to process.

Mike.

 

[Analizer1]

i will look into the thread pool been on my mind...
i haven't used it yet

thanks

 

[Jon Skeet [C# MVP]]

Consider replacing your loop with

foreach (transaction tran in IncomingTransactions()) {
ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadProc), tran);
}

static void ThreadProc(Object stateInfo) {
transaction tran = (transaction)stateInfo;
// Process tran.
}

Doing this will allow the framework to handle the backlog and you don't need
to deal with arrays, etc. No timers are needed, except maybe to start the
foreach loop. A better method would be to use a callback delegate to start
the foreach loop and then you would only start processing when there are
transactions to process.

That all seems a little bit more complicated than is necessary, to be
honest - and would certainly make debugging harder. It sounds like a
loop would be absolutely fine here.

 

[Christopher Van Kirk]

Even if you had a UI, calling DoEvents() is a bad thing to do.


As others have said, you should be more specific as to what you want to
do. Calling Sleep() does in fact cause the thread to yield. But there
are usually much better ways to manage that. Thread.Sleep() isn't nearly
as bad as Application.DoEvents(), but it's still overused.

Pete

Sorry to interrupt, but you assert here that calling DoEvents is a bad
thing to do. Why is that?