Win32 Programming

							Win32 Programming
Lesson 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 pf
    nCallback,
       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 pvFiberExecution
        Context);
       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