Win32 ProgrammingLesson 13: Thread Pooling(Wow, Java is good for something…)

Where are we? We know everything there is to know about

threads in Windows Not But there’s only another 2 lectures on this Introduce a simplifying idea: thread pooling

What is Thread Pooling Thread pooling allows us to let the OS create and

destroy threads for us Each worker thread gets woken up when there’s a

job to do The OS decides whether to create a new thread or

wait for an existing one Caveat emptor: setting up a thread pool is quite

expensive – the wins come on continued reuse

Scenario 1: Call functions asynchronously Very common problem Example: a server which spawns a worker

thread to serve a particular client In this case, the function

QueueUserWorkItem is quite handy

QueueUserWorkItem BOOL QueueUserWorkItem(

   PTHREAD_START_ROUTINE pfnCallback,    PVOID pvContext,    ULONG dwFlags); 

Queues a thread work item and returns immediately Callback function must have the form:

DWORD WINAPI WorkItemFunc(PVOID pvContext); Note the return code is ignored

What do you Notice? No call to _beginthreadex or CreateThread The system creates and manages threads for

you Can gain efficiency as threads are re-used, not

recreated for each new work item (system spends less time creating and destroying threads)

Beware Because the system is managing the threads,

you need to be very careful if you put your thread to sleep and wait for an asynchronous request (like IO) Set dwFlags to WT_EXECUTEINIOTHREAD Need to help the system decide that a thread may

take a long time to complete (so set WT_EXECUTELONGFUNCTION)

Call Functions at Timed Intervals Create a queue:

HANDLE CreateTimerQueue(); Create timers in the queue:

BOOL CreateTimerQueueTimer(    PHANDLE phNewTimer,     HANDLE hTimerQueue,    WAITORTIMERCALLBACK pfnCallback,     PVOID pvContext,     DWORD dwDueTime,     DWORD dwPeriod,     ULONG dwFlags); 

Timer work function Must be of form:

VOID WINAPI WaitOrTimerCallback(    PVOID pvContext,     BOOL fTimerOrWaitFired);  fTimerOrWaitFired is always TRUE

WT_EXECUTEINTIMERTHREAD is interesting Executes in timer thread Very dangerous, but useful when used correctly

Deleting Timers Must do this even for one-shot timers

BOOL DeleteTimerQueueTimer(    HANDLE hTimerQueue,     HANDLE hTimer,    HANDLE hCompletionEvent); 

Blocks until completion if hCompletionEvent is INVALID_HANDLE_VALUE

But… Can pass NULL to the timer for

hCompletionEvent In this case, the Timer is deleted ASAP, but you

won’t know when Finally, can pass an Event Kernel Object

Sets event when the timer is actually deleted

Scenario 3: KO Signaled Lots of applications spawn a thread to wait on

completion of a Kernel Object Wasteful of resources – if this happens a lot better to

use a thread pool CPU Intensive operation when you create/destroy threads Still better than a process

API BOOL RegisterWaitForSingleObject(

   PHANDLE phNewWaitObject,     HANDLE hObject,    WAITORTIMERCALLBACK pfnCallback,     PVOID pvContext,    ULONG dwMilliseconds,    ULONG dwFlags); 

hObject is the object to wait on Time is between 0 and INFINITE

Unregistering a Wait If the desired object gets signaled multiple times, the

Wait object will be woken up multiple times Unless of course you set WT_EXECUTEONLYONCE

But, you must still call: BOOL UnregisterWaitEx(

   HANDLE hWaitHandle,    HANDLE hCompletionEvent); 

Call Functions on I/O Common scenario

Wish to call a function when an asynchronous I/O event completes

You may want to look up “I/O Completion Ports”

Function Format BOOL BindIoCompletionCallback(

   HANDLE hDevice,    POVERLAPPED_COMPLETION_ROUTINE pfnCallback,    ULONG dwFlags); 

Callback function of form: VOID WINAPI OverlappedCompletionRoutine(

   DWORD dwErrorCode,    DWORD dwNumberOfBytesTransferred,    POVERLAPPED pOverlapped); 

Fibers The idea came when MS thought about

application developers porting applications from UNIX to Windows

UNIX lacks the same threading functionality that Windows has, and so implements “threading” quite differently

Fibers make port a lot easier… but they are no substitute for native Windows threads

A what? Every thread contains one or more fibers As far as the Kernel is concerned, each thread

gets preemptively scheduled The thread decides which fiber to execute Only one fiber gets executed at a time

API First, must convert the existing thread to a Fiber:

PVOID ConvertThreadToFiber(PVOID pvParam); This function allocates memory (about 200 bytes) for the

fiber's execution context which contains: A user-defined value that is initialized to the value passed to

ConvertThreadToFiber's pvParam argument The head of a structured exception handling chain The top and bottom memory addresses of the fiber's stack (When

you convert a thread to a fiber, this is also the thread's stack.) Various CPU registers, including a stack pointer, an instruction

pointer, and others

Create Additional Fibers No point ever converting a thread if you don’t

do this! PVOID CreateFiber(

   DWORD dwStackSize,     PFIBER_START_ROUTINE pfnStartAddress,    PVOID pvParam);

Function API is: VOID WINAPI FiberFunc(PVOID pvParam);

Executing Fibers To make the new fiber execute you call:

VOID SwitchToFiber(PVOID pvFiberExecutionContext);

This stores needed information on the current fiber and sends processing to the new one

It’s the only way a fiber can get CPU time Destroy using DeleteFiber