Home > Articles > Programming > Windows Programming

  • Print
  • + Share This
This chapter is from the book

.NET Application Model

Serialization gave you a concrete example of the flexible environment the .NET Framework provides for writing code. Now let us take a look at the model in which .NET applications run. The Win32 environment in which a program runs is called its process. This environment consists of

  • An address space in which the code and data of the program resides.

  • A set of environment variables that is associated with the program.

  • A current drive and directory.

  • One or more threads.

Threads

A thread is the actual execution path of a program's code. One or more threads run inside of a process to allow for multiple execution paths inside of a process. For example, with multiple threads a program can update the user interface with partial results on one thread as a calculation proceeds on another thread. All threads in the same process share the process environment so that all the threads can access the process memory.

Threads are scheduled by the operating system. Processes and application domains10 are not scheduled. Threads are periodically given a limited timeslice in which to run so that they can share the processor with other threads. Higher priority threads will get to run more often than lower priority threads. After some time elapses, a thread will get another chance to run. When a thread is swapped back in, it resumes running from the point it was at when it was swapped out.

Threads maintain a context that is saved and restored when the operating system's scheduler switches from one thread to another. A thread's context includes the CPU registers and stack that contain the state of the executing code.

The System::Threading::Thread class models an executing thread. The Thread object that represents the current executing thread can be found from the static property Thread::CurrentThread.

Unless your code runs on a multiprocessor machine, or you are trying to use time while a uniprocessor waits for some event such as an I/O event, multiple threads do not result in any time saved for your computing tasks. It does, however, make the system seem more responsive to tasks requiring user interaction. Using too many threads can decrease performance, as thread management overhead and contention between competing threads burdens the CPU.

To help you understand threads, we have a multiple-step Threading example11 that uses the Customer and Hotel assemblies from the case study to make reservations. Let us look first at Step 0.

.NET threads run as delegates defined by the ThreadStart class. The delegate returns void and takes no parameters.

public __gc __delegate void ThreadStart();

The NewReservation class has a public member function, MakeReservation, that will define the thread function. Since the thread function takes no parameters, any data that this function uses is assigned to fields in the NewReservation instance.

The thread delegate is created and passed as a parameter to the constructor that creates the Thread object. The Start method on the Thread object is invoked to begin the thread's execution. When we discuss the asynchronous programming model, we will show you how to pass parameters to a thread delegate. The program now has two threads: the original one that executed the code to start the thread and now the thread we just created that attempts to make a hotel reservation.

   public __gc class NewReservation
   {
      ...
   public:
      ...
      void MakeReservation()
      {
         Console::WriteLine(
            "Thread {0} starting.",
            Thread::CurrentThread->
               GetHashCode().ToString());
         ...
         ReservationResult *result =
            hotelBroker->MakeReservation(
            customerId, city, hotel, date, numberDays);
         ...
      }
   };

Then, in the Main method, the following code starts the thread, using a delegate:

   NewReservation *reserve1 =
      new NewReservation(customers, hotelBroker);

   reserve1->customerId = 1;
   reserve1->city = "Boston";
   reserve1->hotel = "Presidential";
   reserve1->sdate = "12/12/2001";
   reserve1->numberDays = 3;

   // create delegate for threads
   ThreadStart *threadStart1 = new ThreadStart(
      reserve1,
      reserve1->MakeReservation);

   Thread *thread1 = new Thread(threadStart1);
   Console::WriteLine(
      "Thread {0} starting a new thread.",
      Thread::CurrentThread->
         GetHashCode().ToString());
   thread1->Start();

To cause the original thread to wait until the second thread is done, the Join method on the Thread object is called. The original thread now blocks (waits) until the reservation thread is complete. The results of the reservation request are written to the console by the reservation thread.

   // Block this thread until the worker thread is done
   thread1->Join();
   Console::WriteLine("Done!");

Thread Synchronization

An application can create multiple threads. Look at the code in Step 1 of the Threading example. Now multiple reservation requests are being made simultaneously.

   NewReservation *reserve1 =
      new NewReservation(customers, hotelBroker);
   ...

   NewReservation *reserve2 =
      new NewReservation(customers, hotelBroker);
   ...

   // create delegate for threads
   ThreadStart *threadStart1 = new ThreadStart(
      reserve1,
      reserve1->MakeReservation);
   ThreadStart *threadStart2 = new ThreadStart(
      reserve2,
      reserve2->MakeReservation);

   Thread *thread1 = new Thread(threadStart1);
   Thread *thread2 = new Thread(threadStart2);

   Console::WriteLine(
      "Thread {0} starting a new thread.",
      Thread::CurrentThread->
         GetHashCode().ToString());
   thread1->Start();
   thread2->Start();

   // Block this thread until the worker thread is done
   thread1->Join();
   thread2->Join();

The problem with our reservation system is that there is no guarantee that one thread will not interfere with the work being done by the other thread. Since threads run for only a small period before they give up the processor to another thread, they may not be finished with whatever operation they were working on when their timeslice is up. For example, they might be in the middle of updating a data structure. If another thread tries to use the information in that data structure or to update the data structure, the results of those operations will be inconsistent and incorrect, or a program crash could result (i.e., if references to obsolete structures were not yet updated, an unhandled exception could occur).

Let us look at one of several places in the customer and reservation code where we could have a problem. Examine the code for Broker::Reserve in Broker.h. First, a check is made of the existing bookings for a given hotel for a given date to see if there are rooms available. Then, if a room is available, it is reserved. Note that we have added a call to Thread::Sleep between the code that checks for room availability and the code that reserves a room, which will be explained shortly.

   ...
   // Check if rooms are available for all dates
   for (int i = day; i < day + numDays; i++)
   {
      if (numCust[i, unitid] >= unit->capacity)
      {
         result->ReservationId = -1;
         result->Comment = "Room not available";
         return result;
      }
   }

   Console::WriteLine(
      "Thread {0} finds the room is available in
@@      Broker::Reserve",
      Thread::CurrentThread->
         GetHashCode().ToString());

   Thread::Sleep(0);

   // Reserve a room for requested dates
   for (int i = day; i < day + numDays; i++)
      numCust[i, unitid] += 1;
   ...

This code can produce inconsistent results! One of the threads could be swapped out after it finds that the last room is available, but before it gets a chance to make the booking. The other thread could then run, find the same available room and make the booking. When the first thread runs again, it starts from where it left off, and it will also book the same last room at the hotel.

To simulate this occurrence, this step (Step 1) of the Threading example puts a Thread::Sleep call between the code that checks for room availability and the code that makes the booking. The Sleep(0) call will cause the thread to stop executing and give up the remainder of its timeslice.

To ensure that we see the thread contention problem occur,12 we have only one room in the entire hotel! We then set up our program so that the two threads try to reserve the only room at the hotel for the same date. Examine the code in the Main routine that sets this up:

   hotelBroker->AddHotel(
      "Boston",
      "Presidential",
      1, //only one room in entire hotel!
      (Decimal) 10000);
   ...
   NewReservation *reserve1 =
      new NewReservation(customers, hotelBroker);
   reserve1->customerId = 1;
   reserve1->city = "Boston";
   reserve1->hotel = "Presidential";
   reserve1->sdate = "12/12/2001";
   reserve1->numberDays = 3;

   NewReservation *reserve2 =
      new NewReservation(customers, hotelBroker);
   reserve2->customerId = 2;
   reserve2->city = "Boston";
   reserve2->hotel = "Presidential";
   reserve2->sdate = "12/13/2001";
   reserve2->numberDays = 1;

Running the program will give results that look something like this:

Added Boston Presidential Hotel with one room.
Thread 3 starting a new thread.
Thread 5 starting.
Thread 6 starting.
Reserving for Customer 2 at the Boston Presidential Hotel on
12/13/2001 12:00:00 AM for 1 days
Reserving for Customer 1 at the Boston Presidential Hotel on
12/12/2001 12:00:00 AM for 3 days
Thread 6 entered Broker::Reserve
Thread 6 finds the room is available in Broker::Reserve
Thread 5 entered Broker::Reserve
Thread 5 finds the room is available in Broker::Reserve
Thread 6 left Broker::Reserve
Reservation for Customer 2 has been booked
ReservationId = 1
Thread 5 left Broker::Reserve
Reservation for Customer 1 has been booked
ReservationId = 2
ReservationRate = 10000
ReservationCost = 30000
Comment = OK
ReservationRate = 10000
ReservationCost = 10000
Comment = OK
Done!

Unfortunately, both customers get to reserve the last (only) room on December 13! Note how one thread enters the Reserve method and finds the room is available before it gets swapped out. Then, the other thread enters Reserve and also finds the room is available before it gets swapped out. Both threads then book the same room.

Operating systems provide means for synchronizing the operation of multiple threads or multiple processes accessing shared resources. The .NET Framework provides several mechanisms to prevent threading conflicts.

Every object in the .NET Framework can be used to provide a synchronized section of code (critical section). Only one thread at a time can execute within such a section. If one thread is already executing inside that synchronized code section, any other threads that attempt to access that section will block (wait) until the executing thread leaves that code section.

Synchronization with Monitors

The System::Threading::Monitor class allows threads to synchronize on an object to avoid the data corruption and indeterminate behavior that can result from race conditions. Step 2 of the Threading example demonstrates the use of the Monitor class with the this pointer of the HotelBroker instance.

   ReservationResult *Reserve(Reservation *res)
   {
      Console::WriteLine(
         "Thread {0} trying to enter Broker::Reserve",
         Thread::CurrentThread->
            GetHashCode().ToString());
      Monitor::Enter(this);
      ... (thread contentious code goes here)
      Monitor::Exit(this);
      return result;
   }

The thread that first calls the Monitor::Enter(this) method will be allowed to execute the code of the Reserve method because it will acquire the Monitor lock based on the this pointer. Subsequent threads that try to execute the same code will have to wait until the first thread releases the lock with Monitor::Exit(this). At that point they will be able to call Monitor::Enter(this) and acquire the lock.

A thread can call Monitor::Enter several times, but each call must be balanced by a call to Monitor::Exit. If a thread wants to try to acquire a lock, but does not want to block, it can use the Monitor::TryEnter method.

Now that we have provided synchronization, the identical case tried in Step 1 does not result in one reservation too many for the hotel. Notice how the second thread cannot enter the Reserve method until the first thread that entered has left. This solves our thread contention problem and enforces the rule that the same room cannot be booked by two customers for the same date.

Added Boston Presidential Hotel with one room.
Thread 3 starting a new thread.
Thread 5 starting.
Thread 6 starting.
Reserving for Customer 2 at the Boston Presidential Hotel on
12/13/2001 12:00:00 AM for 1 days
Thread 6 trying to enter Broker::Reserve
Thread 6 entered Broker::Reserve
Thread 6 finds the room is available in Broker::Reserve
Thread 6 left Broker::Reserve
Reservation for Customer 2 has been booked
ReservationId = 1
Reserving for Customer 1 at the Boston Presidential Hotel on
12/12/2001 12:00:00 AM for 3 days
Thread 5 trying to enter Broker::Reserve
Thread 5 entered Broker::Reserve
Reservation for Customer 1 could not be booked
Room not available
ReservationRate = 10000
ReservationCost = 10000
Comment = OK
Done!

Notification with Monitors

A thread that has acquired a Monitor lock can wait for a signal from another thread that is synchronizing on that same object without leaving the synchronization block. The thread invokes the Monitor::Wait method and relinquishes the lock. When notified by another thread, it reacquires the synchronization lock.

A thread that has acquired a Monitor lock can send notification to another thread waiting on the same object with the Pulse or the PulseAll methods. It is important that the thread be waiting when the pulse is sent; otherwise, if the pulse is sent before the wait, the other thread will wait forever and will never see the notification. This is unlike the reset events discussed later in this chapter. If multiple threads are waiting, the Pulse method will put only one thread on the ready queue to run. The PulseAll will put all of them on the ready queue.

The pulsing thread no longer has the Monitor lock, but is not blocked from running. Since it is no longer blocked, but does not have the lock, to avoid a deadlock or race condition, this thread should try to reacquire the lock (through a Monitor::Enter or Wait) before doing any potentially damaging work.

The PulseAll example illustrates the Pulse and PulseAll methods. Running the example produces the following output:

First thread: 2 started.
Thread: 5 started.
Thread: 5 waiting.
Thread: 6 started.
Thread: 6 waiting.
Thread 5 sleeping.
Done.
Thread 5 awake.
Thread: 5 exited.
Thread 6 sleeping.
Thread 6 awake.
Thread: 6 exited.

The class X has a field "o" of type Object that will be used for a synchronization lock.

The class also has a method Test that will be used as a thread delegate. The method acquires the synchronization lock, and then waits for a notification. When it gets the notification, it sleeps for half a second, and then relinquishes the lock.

The main method creates two threads that use the X::Test method as their thread delegate and share the same object to use for synchronization. It then sleeps for 2 seconds to allow the threads to issue their wait requests and relinquish their locks. It then calls PulseAll to notify both waiting threads and relinquishes its hold on the locks. Eventually, each thread will reacquire the lock, write a message to the console, and relinquish the lock for the last time.

__gc class X
{
private:
   Object *o;
public:
   X(Object *o)
   {
      this->o = o;
   }
   void Test()
   {
      try
      {
         long threadId =
            Thread::CurrentThread->GetHashCode();
         Console::WriteLine(
            "Thread: {0} started.", threadId.ToString());
         Monitor::Enter(o);
         Console::WriteLine(
            "Thread: {0} waiting.", threadId.ToString());
         Monitor::Wait(o);
         Console::WriteLine(
            "Thread {0} sleeping.", threadId.ToString());
         Thread::Sleep(500);
         Console::WriteLine(
            "Thread {0} awake.", threadId.ToString());
         Monitor::Exit(o);
         Console::WriteLine(
            "Thread: {0} exited.", threadId.ToString());
      }
      catch(Exception *e)
      {
         long threadId =
            Thread::CurrentThread->GetHashCode();
         Console::WriteLine(
            "Thread: {0} Exception: {1}",
            threadId.ToString(), e->Message);
         Monitor::Exit(o);
      }
   }
};

__gc class Class1
{
public:
   static Object *o = new Object;
   static void Main()
   {
      Console::WriteLine(
         "First thread: {0} started.",
         Thread::CurrentThread->GetHashCode().ToString());

      X *a = new X(o);
      X *b = new X(o);

      ThreadStart *ats = new ThreadStart(a, X::Test);
      ThreadStart *bts = new ThreadStart(b, X::Test);

      Thread *at = new Thread(ats);
      Thread *bt = new Thread(bts);

      at->Start();
      bt->Start();

      // Sleep to allow other threads to wait on the
      // object before the Pulse
      Thread::Sleep(2000);
      Monitor::Enter(o);

      Monitor::PulseAll(o);
      //Monitor::Pulse(o);

      Monitor::Exit(o);

      Console::WriteLine("Done.");
   }
};

Comment out the PulseAll call and uncomment the Pulse call, and only one thread completes because the other thread is never put on the ready queue. Remove the Sleep(2000) from the main routine, and the other threads block forever because the pulse occurs before the threads get a chance to call the Wait method, and hence they will never be notified. These methods can be used to coordinate several threads' use of synchronization locks.

The Thread::Sleep method causes the current thread to stop execution (block) for a given time period. Calling Thread::Suspend will cause the thread to block until Thread::Resume is called by another thread on that same thread. Threads can also block because they are waiting for another thread to finish (Thread::Join). This method was used in the Threading examples so that the main thread could wait until the reservation requests were completed. Threads can also block because they are waiting on a synchronization lock (critical section).

Calling Thread::Interrupt on the blocked thread can awaken it. The thread will receive a ThreadInterruptedException. If the thread does not catch this exception, the runtime will catch the exception and kill the thread.

If, as a last resort, you have to kill a thread outright, call the Thread::Abort method on the thread. Thread::Abort causes the ThreadAbortException to be thrown. This exception cannot be caught, but it will cause all the finally blocks to be executed. In addition, Thread::Abort does not cause the thread to wake up from a wait.

Since finally blocks may take a while to execute, or the thread might be waiting, aborted threads may not terminate immediately. If you need to be sure that the thread has finished, you should wait on the thread's termination using Thread::Join.

Synchronization Classes

The .NET Framework has classes that represent the standard Win32 synchronization objects. These classes all derive from the abstract WaitHandle class. This class has static methods, WaitAll and WaitAny, that allow you to wait on a set or just one of a set of synchronization objects being signaled. It also has an instance method, WaitOne, that allows you to wait for this instance to be signaled. How the object gets signaled depends on the particular type of synchronization object that is derived from WaitHandle.

A Mutex object is used for interprocess synchronization. Monitors and synchronized code sections work only within one process. An AutoResetEvent and ManualResetEvent are used to signal whether an event has occurred. An AutoResetEvent remains signaled until a waiting thread is released. A ManualResetEvent remains signaled until its state is set to unsignaled with the Reset method. Hence, many threads could be signaled by this event. Unlike Monitors, code does not have to be waiting for the signal before the pulse is set for the reset events to signal a thread.

The framework has provided classes to solve some standard threading problems. The Interlocked class methods allow atomic operations on shared values such as increment, decrement, comparison, and exchange. ReaderWriterLock is used to allow single-writer, multiple-reader access to data structures. The ThreadPool class can be used to manage a pool of worker threads.

Automatic Synchronization

You can use attributes to synchronize the access to instance methods and fields of a class. Access to static fields and methods is not synchronized. To do this, you derive the class from the class System::ContextBoundObject and apply a Synchronization attribute to the class. This attribute cannot be applied to an individual method or field.

The attribute is found in the System::Runtime::Remoting::Contexts namespace. It describes the synchronization requirements of an instance of the class to which it is applied. You can pass one of four values, which are static fields of the SynchronizationAttribute class, to the SynchronizationAttribute constructor: NOT_SUPPORTED, SUPPORTED, REQUIRED, REQUIRES_NEW. The Threading example Step 3 illustrates how to do this.

   ...
   using namespace System::Runtime::Remoting::Contexts;
   ...
   //SynchronizationAttribute::REQUIRED is 4
   [Synchronization(4)]
   public __gc __abstract class Broker :
      public ContextBoundObject
   {
      ...
   };
   ...

In order for the CLR to make sure that the thread in which an object's methods run is synchronized properly, the CLR has to track the threading requirements of the object. This state is referred to as the context of the object. If one object needs to be synchronized, and another does not, they are in two separate contexts. The CLR has to acquire a synchronization lock on behalf of the code when a thread that is executing a method on the object that does not need to be synchronized starts executing a method on an object that does. The CLR knows that this has to be done because it can compare the threading requirements of the first object with the threading requirements of the second object by comparing their contexts.

Objects that share the same state are said to live in the same context. For example, two objects that do not need to be synchronized can share the same context. ContextBoundObject and contexts are discussed in more detail in the section on contexts.

With this intuitive understanding of contexts, we can now explain the meaning of the various Synchronization attributes. NOT_SUPPORTED means that the class cannot support synchronization of its instance methods and fields and therefore must not be created in a synchronized context. REQUIRED means that the class requires synchronization of access to its instance methods and fields. If a thread is already being synchronized, however, it can use the same synchronization lock and live in an existing synchronization context. REQUIRES_NEW means that not only is synchronization required, but access to its instance methods and fields must be with a unique synchronization lock and context. SUPPORTED means that the class does not require synchronization of access to its instance methods and fields, but a new context does not have to be created for it.

You can also pass a bool flag to the constructor to indicate if reentrancy is required. If required, call-outs from methods are synchronized. Otherwise, only calls into methods are synchronized.

With the Synchronization attribute, there is no need for Monitor::Enter and Monitor::Exit in the Broker::Reserve method.

Just as in Step 2, this example attempts to make two reservations for the last room in a hotel. Here is the output from running this example:

Added Boston Presidential Hotel with one room.
Thread 13 starting a new thread.
Thread 28 starting.
Thread 29 starting.
Reserving for Customer 1 at the Boston Presidential Hotel on
12/12/2001 12:00:00 AM for 3 days
Thread 28 entered Broker::Reserve
Thread 28 finds the room is available in Broker::Reserve
Thread 28 left Broker::Reserve
Reservation for Customer 1 has been booked
ReservationId = 1
ReservationRate = 10000
ReservationCost = 30000
Comment = OK
Reserving for Customer 2 at the Boston Presidential Hotel on
12/13/2001 12:00:00 AM for 1 days
Thread 29 entered Broker::Reserve
Thread 29 left Reserve.
Reservation for Customer 2 could not be booked
Room not available
Done!

As in the previous case, the second thread could not enter the Reserve method until the thread that entered first finished. Only one reservation is made.

What is different about using this automatic approach is that you get the synchronization in all the methods of the class whether you need it or not. Accessing other shared data via other methods in the class is also blocked. You get this behavior whether you want it or not.

Note how only one thread can be in any method of the class at any given time. Assume that you added another method to the class named CancelReservation. If one thread called CancelReservation, it would block all other threads from calling other methods in the class, including MakeReservation. With a reservation system, this is the behavior you would want, since you do not want the MakeReservation attempt to use a data structure that might be in the middle of being modified. In some situations, however, this is not desirable and reduces performance due to unnecessary blocking. The resulting increase in contention can interfere with scalability, since you are not just locking around the specific areas that need synchronizing.

The attribute approach is simpler than using critical sections. You do not have to worry about the details of getting the synchronization implemented correctly. On the other hand, you get behavior that reduces scalability. Different applications or different parts of the same application will benefit from the approach that makes the most sense.

Thread Isolation

An exception generated by one thread will not cause another thread to fail. The ThreadIsolation example demonstrates this.

__gc class tm
{
public:
   void m()
   {
      Console::WriteLine(
         "Thread {0} started",
         Thread::CurrentThread->GetHashCode().ToString());
      Thread::Sleep(1000);
      for(int i = 0; i < 10; i++)
         Console::WriteLine(i);
      Console::WriteLine(
         "Thread {0} done",
         Thread::CurrentThread->GetHashCode().ToString());
   }
};

__gc class te
{
public:
   void tue()
   {
      Console::WriteLine(
         "Thread {0} started",
         Thread::CurrentThread->GetHashCode().ToString());
      Exception *e = new Exception("Thread Exception");
      throw e;
   }
};

__gc class ThreadIsolation
{
public:
   static void Main()
   {
      tm *tt = new tm;
      te *tex = new te;

      // create delegate for threads
      ThreadStart *ts1 = new ThreadStart(tt, tm::m);
      ThreadStart *ts2 = new ThreadStart(tex, te::tue);

      Thread *thread1 = new Thread(ts1);
      Thread *thread2 = new Thread(ts2);

      Console::WriteLine(
         "Thread {0} starting new threads.",
         Thread::CurrentThread->GetHashCode().ToString());
      thread1->Start();
      thread2->Start();

      Console::WriteLine(
         "Thread {0} done.",
         Thread::CurrentThread->GetHashCode().ToString());
   }
};

The following output is generated. Note how the second thread can continue to write out the numbers even though the first thread has aborted from the unhandled exception. Note also how the "main" thread that spawned the other two threads can finish without causing the other threads to terminate.

Thread 2 starting new threads.
Thread 2 done.
Thread 5 started
Thread 6 started

Unhandled Exception: System.Exception: Thread Exception
   @@at te.tue() in c:\oi\netcpp\chap8\threadisolation@@   threadisolation.h:line 32
0
1
2
3
4
5
6
7
8
9
Thread 5 done

The AppDomain class (discussed later in the chapter) allows you to set up a handler to catch an UnhandledException event.

Synchronization of Collections

Some lists, such as TraceListeners, are thread safe. When this collection is modified, a copy is modified and the reference is set to the copy. Most collections, like ArrayList, are not thread safe. Making them automatically thread safe would decrease the performance of the collection even when thread safety is not an issue.

An ArrayList has a static Synchronized method to return a thread-safe version of the ArrayList. The IsSynchronized property allows you to test if the ArrayList you are using is the thread-safe version. The SyncRoot property can return an object that can be used to synchronize access to a collection. This allows other threads that might be using the ArrayList to be synchronized with the same object.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020