Udostępnij za pośrednictwem


Managed Threading Overview

Microsoft Silverlight will reach end of support after October 2021. Learn more.

A Silverlight-based application runs in a sandboxed application domain. As with all applications, threads are the basic unit to which an operating system allocates processor time. A Silverlight-based application has a main application thread and can use additional threads that you create or that are supplied by the thread pool. Each thread maintains exception handlers, a scheduling priority, and a set of structures the system uses to save the thread context until it is scheduled. The thread context includes all the information the thread needs to seamlessly resume execution, including the thread's set of CPU registers and stack, in the address space of the thread's host process.

An operating system that supports preemptive multitasking creates the effect of simultaneous execution of multiple threads from multiple processes. It does this by dividing the available processor time among the threads that need it, allocating a processor time slice to each thread, one after another. The currently executing thread is suspended when its time slice elapses, and another thread resumes running. When the system switches from one thread to another, it saves the thread context of the preempted thread and reloads the saved thread context of the next thread in the thread queue.

The length of the time slice depends on the operating system and the processor. Because each time slice is small, multiple threads appear to be executing at the same time, even if there is only one processor. This is actually the case on multiprocessor systems, where the executable threads are distributed among the available processors.

When to Use Multiple Threads

Software that requires user interaction must react to the user's activities as rapidly as possible to provide a rich user experience. At the same time, however, it must do the calculations necessary to present data to the user as fast as possible.

Advantages of Multiple Threads

Using more than one thread is the most powerful technique available to increase responsiveness to the user and process the data necessary to get the job done at almost the same time. On a computer that has one processor, multiple threads can create this effect, taking advantage of the small periods of time between user events to process the data in the background.

Furthermore, an application that is written to use multiple threads benefits from a significant increase in user satisfaction, without requiring any modification, when it is run on a computer that has more than one processor.

Disadvantages of Multiple Threads

Threading is complicated. The more threads you have running, the more opportunities you have for deadlocks and race conditions. (See Best Practices for Managed Threading.) It is difficult to test multithreaded applications, because using multiple threads multiplies the ways in which different elements of your application can interact. When bugs are found, it can be difficult to isolate their causes.

Threads use resources. Each thread has its own stack, which increases the size of your program's working set. Keeping track of a large number of threads and switching between thread contexts consumes significant processor time. If there are too many threads, most of them will not make significant progress.

Threads require synchronization. Providing shared access to resources such as user interface (UI) elements can create conflicts; most UI elements are not thread safe. Failure to synchronize access properly can lead to data corruption, deadlocks, and race conditions.

Threading and Application Design

We recommend that you use as few threads as possible, to reduce programming problems and to minimize the use of operating-system resources. We recommend that you consider using high-level threading features, such as the BackgroundWorker class and the thread pool. In particular, BackgroundWorker simplifies threading by providing an event-driven model for communicating safely between background tasks and your application's main thread.

The ThreadPool class provides another easy way to handle multiple threads for relatively short tasks that will not block other threads. For information about the thread pool and a discussion of when to create your own threads, see The Managed Thread Pool.

Threading and Exceptions

It is important to handle exceptions in threads. Unhandled exceptions in threads, even background threads, generally terminate your application. The user experiences this as a page error. For more information, see Exceptions in Managed Threads.

Foreground and Background Threads

A managed thread is either a background thread or a foreground thread. In Silverlight, there is no difference in behavior between the two.

Use the Thread.IsBackground property to determine whether a thread is a background or a foreground thread, or to change its status. A thread can be changed to a background thread at any time by setting its IsBackground property to true.

Threads that belong to the managed thread pool are background threads. All threads that enter the managed execution environment from unmanaged code are marked as background threads. All threads generated by creating and starting a new Thread object are by default foreground threads.

Thread State

The Thread.ThreadState property provides a bitmask that indicates the thread's current state. A thread is always in at least one of the possible states in the ThreadState enumeration, and can be in multiple states at the same time.

Important noteImportant Note:

Thread state is of interest only in a few debugging scenarios. Your code should never use thread state to synchronize the activities of threads.

For more information, see the ThreadState enumeration.

In This Section

Topic

Description

Creating Threads and Passing Data at Start Time

Discusses and demonstrates the creation of managed threads, including how to pass data to new threads and how to get data back.

Exceptions in Managed Threads

Describes the behavior of unhandled exceptions in threads.

Synchronizing Data for Multithreading

Describes strategies for synchronizing data in classes that will be used with multiple threads.

Thread Local Storage

Describes thread-relative storage mechanisms.

Reference

Topic

Description

Thread

Provides reference documentation for the Thread class, which represents a managed thread, whether it came from unmanaged code or was created in a managed application.

ThreadPool

Provides a pool of threads that can be used to post work items, process asynchronous I/O, wait on behalf of other threads, and process timers.

BackgroundWorker

Provides a safe way to implement multithreading with user interface objects.

Topic

Description

Best Practices for Managed Threading

Discusses how to avoid deadlocks and race conditions, how multithreading works on single-processor and multiprocessor computers, and other threading issues.

Threading Objects and Features

Describes the managed classes you can use to synchronize the activities of threads and the data of objects accessed on different threads, and provides an overview of thread pool threads.

Synchronization Primitives

Describes the managed classes that are used to synchronize the activities of multiple threads.

The Managed Thread Pool

Explains the ThreadPool class, which enables you to request a thread to execute a task without having to do any thread management yourself.