Post on 12-Jan-2016
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