Board index » Visual Studio » Pausing a Thread

Visual Studio221
Does anyone know how to "pause" a thread and not have it take up CPU cycles?



I know SQLServer does it because it using a thread pool, and I suspect this

type of thing is used else where.



I've tried it with for-loops, while-loops, but it takes up too much CPU

time...it actually pegs the CPU to 100%.



So, I'm looking for other ways to pause and restart a thread.



Thanks


-

Maybe I'll try to answer my own question...

Will SuspendThread(...) work for this?





"Bupp Phillips" <hello@noname.com>wrote in message



-

Win32 provides SuspendThread/ResumeThread API call. Both APIs maintain an

internal counter. When you make a call to SuspendThread it increases the

count and decreases it when ResumeThread is called.



It would be better if you could write your own "Pause" function, possibily

using event signalling in your loop. The loop should go into 'idle' or

'sleep' mode when you invoke 'Pause' and continue doing processing when you

call your resume function. For example, you can use semaphore or event

object to control your thread:



ABC::ABC()

{

//Create a named event object

CreateEvent(...);

}



void ABC:: MyWorkerThread()

{

while (TRUE)

{

if (m_bPause) //Flag to indicate if thread should be suspended

{

WaitForSingleObject(m_hEvent, WAIT_INFINITE);

m_bPause = FALSE;

}



//Your Processing goes here

}

}



void ABC::Pause()

{

m_bPause = TRUE;

}



void ABC::Resume()

{

//Open Event object

OpenEvent(..)



//Signal the event

SetEvent(..)

}



Regards,

KC



"Bupp Phillips" <hello@noname.com>wrote in message



-

You should avoid using SuspendThread/ResumeThread whenever possible as you

know the "state" of your thread better. You might want to wait till a full

cycle of processing is done before suspending the thread. In this case,

SuspendThread will not guarantee you that. In the worst scenario, calling

SuspendThread can cause deadlock in your application if the thread owns a

synchronization object such as event or semaphore and another thread tries

to obtain a synchronization object owned by the suspended thread.



Regards,

KC





"Bupp Phillips" <hello@noname.com>wrote in message



-

Read CreateEvent (and about other synchronization objects). SetEvent,

WaitForSingleObject, Sleep(), and other functions.



"Bupp Phillips" <hello@noname.com>wrote in message



-

This application has the potential to have possibly 100's or 1000's of

threads running.

It will be running on a 4 or 8 way processor box.



So will the use of Events/Semaphores be too resource heavy for such an

application?



Thanks





"KC" <kianchuantan@yahoo.com>wrote in message



-

Thread is much heavier resource than an event. A thread eats a megabyte of

the virtual space.



I'd also strongly advise AGAINST using SuspendThread/ResumeThread. There is

no reliable scenario they can be used, other than for debugging.



You don't need named events in most cases. Unnamed events should be filne.



"Bupp Phillips" <hello@noname.com>wrote in message



-

Agree with Grigoriev...



It is almost certainly that you have to deal with sync objects in

multithreading. The challenge is to avoid deadlock, eliminating race

conditions for shared objects or minimizing the overhead of context

switching. It is a question of using the more efficient concurrency model

and this is very much depends on what the application does.



KC



"Alexander Grigoriev" <alegr@earthlink.net>wrote in message



-

"Alexander Grigoriev" <alegr@earthlink.net>wrote in message





ok, I get the hint that Suspend/ResumeThread are a bad thing.



But I don't think a thread will take a megabyte of memory. On my machine,

the "System" process has 33 threads running and its memory consumption is

only 216K.



But thanks for the advance, I will use events to pause and start my threads.



Thanks





-

For an user mode thread, a megabyte of virtual space is allocated by default

for the thread stack. You can change it, though, by the linker switch.

"System" process has only kernel mode threads, which don't have user mode

stack.



"Bupp Phillips" <hello@noname.com>wrote in message



-

"Bupp Phillips" <hello@noname.com>wrote in message news:<e3I9s1WvDHA.2260@TK2MSFTNGP09.phx.gbl>...



This is basically a bad idea, even on a big multi-processors box.

Remember that at any given time, one processor can only run one

thread. Except if your threads are *really* I/O oriented (ie they

spend all of their time waiting for an I/O to complete - but it must

not be the case since you ask for a way to "Sleep" a thread), your

processors are going to spend most of their time switching from one

thread to another and deciding what thread to run next. You should

look for the concept of "thread pool" instead.





Unless otherwise specified (at compile-time or at thread

creation-time), each thread will have a 1MB space reserved in the

*virtual* address space of the process fot it's stack. It doesn't

means this virtual memory will be commited in real memory immediatly

(if I remember correctly, stack space is commited in 64KB chunks).



However, since you've got 2GB of virtual memory available, minus the

place taken by code, globals and heap, you've got absolutely less than

2000 threads possible per process.



If your threads are in one process, you should better use

CriticalSection, they are less ressource hungry.



Arnaud

MVP - VC

-

"Arnaud Debaene" <adebaene@club-internet.fr>wrote in message

It will use a thread-pool, that is why I need a way to pause a thread, so

that it can be used by something else without the overhead of destorying and

re-creating the thread.





Do you mean to use CriticalSection as a means to "pause" a thread, how would

you use them for that purpose?







-