Win32 Programming Lesson 9: Jobs & Thread Basics

Where are we?  We’ve got processes sort of worked out…  But every process must have a thread associated with it  This lesson, we’ll work on threads – understanding threads is critical to understanding Windows programming  Also, a little bit on jobs…

What is a Job  A collection of processes  For example, imagine interrupting the build in Visual Studio  Windows 2000 offered a new kernel object to allow this

Basic Idea  Create a Job Kernel Object CreateJobObject  Place restrictions on the job object SetInformationJobObject  Start up some processes… CreateProcess But, set CREATE_SUSPENDED flag Assign processes to job Start the primary thread of each process

Termination  You can stop all processes in a job simply by terminating the Job Object TerminateJobObject(HANDLE hJob, UInt uExitCode)

Threads  Each thread is made up of two objects A kernel object used by the Operating System to manage the thread A thread stack that maintains local variables and function parameters as the thread executes

Threads v. Processes  Processes take up a lot more system resources than threads  Processes are inert – they are simply a container for one or more threads  Always solve a problem by adding threads not processes if you possibly can!

When to Create Threads  Many applications only have one thread  The process terminates when the primary thread finishes  However, processes can have as many threads are you like… and there’s no reason for the CPU to be idle (unless you’re on a laptop!) Example: Web browsers have separate threads for IO so the UI remains responsive

When Not to Create Threads  Some things really do need to happen in sequence Word processor, with its own thread for printing… why not? UI’s – have one GetMessage loop, with multiple worker threads  Moral: Don’t use multiple threads just because you can

Creating Threads  Once you’ve got one thread running (i.e. you’ve executed your program) you can start more  See MSDN for an example applicationMSDN  Based upon a thread function which gets called, of form: DWORD WINAPI ThreadFunc(PVOID pvParam)

Caveat Emptor  Use Local variables in threads wherever you can – static and global variables can be modified at any time by other threads, leading to all sorts of interesting race conditions  Your thread function must return a DWORD value

CreateThread  HANDLE CreateThread( PSECURITY_ATTRIBUTES psa, DWORD cbStack, PTHREAD_START_ROUTINE pfnStartA ddr, PVOID pvParam, DWORD fdwCreate, PDWORD pdwThreadID);

Parms  psa: Security attributes – usually NULL if you want the default  cbStack: The amount of stack space to reserve; 0 gets you the default  pfnStartAddr: Pointer to the function to call to start the thread  pvParam: Pointer to any parameters you wish to pass

Bugs  DWORD WINAPI FirstThread(PVOID pvParam) { // Initialize a stack-based variable int x = 0; DWORD dwThreadID; // Create a new thread. HANDLE hThread = CreateThread(NULL, 0, SecondThread, (PVOID) &x, 0, &d wThreadId); // We don't reference the new thread anymore, // so close our handle to it. CloseHandle(hThread); // Our thread is done. // BUG: our stack will be destroyed, but // SecondThread might try to access it. return(0); } DWORD WINAPI SecondThread(PVOID pvParam) { // Do some lengthy processing here. // Attempt to access the variable on FirstThread's stack. // NOTE: This may cause an access violation _ it depends on timing! * ((int *) pvParam) = 5; return(0); }

How to Solve this Problem  Hokey: create a static variable so the memory is allocated away from the thread stack  Better: use proper thread synchronization techniques – but that’s another story

Parms (cntd)  fdwCreate: 0 (get on with it) and CREATE_SUSPENDED (create it paused). See JobLab example for how to use this flag  pdwThreadID: the address of a DWORD in which CreateThread stores the ID assigned to the new thread

Terminating a Thread  Four ways: The thread function returns (good) The thread kills itself by calling ExitThread (bad) Another thread calls TerminateThread (bad) The process containing the thread terminates (bad)  Can use function to get exit code: BOOL GetExitCodeThread( HANDLE hThread, PDWORD pdwExitCode);

Thread Startup

Thread Context  Each thread has its own set of CPU registers  Saved in a CONTEXT structure contained in the thread’s kernel object  IP and SP are the most important  BaseThreadStart is called internally by the OS

BaseThreadStart  Sets up default SEH  System calls the function pointed to in CreateThread, passing in pvParam  On Thread exit, return return code  If an exception is caught, handle it; this involves terminating the entire process not just the offending thread

C/C++ Considerations  Beware: You’re reading about how the OS handles threads. Missing logical “sugar” when considering the C/C++ RTLs  Read the MSDN section on threads – it’s very useful!  Also: _beginthreadex

A Sense of Self  Threads can learn about themselves via: HANDLE GetCurrentProcess() HANDLE GetCurrentThread() Return pseudo-handles not true unique identifiers See also GetProcessTimes and GetThreadTimes Can use DuplicateHandle to get a real handle to the thread