Scribd
Upload
8 views

complete-reference-vb_net_87

Uploaded by

khalid
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
8 views

complete-reference-vb_net_87

Uploaded by

khalid
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

The .

NET Framework's Thread Model

The .NET Framework's Thread Model

The .NET Framework's thread model is represented by the System.Threading namespace, which is
partitioned between the System (classes for thread delegates) and mscorlib assemblies. The classes and
constructs in this namespace contain all the support for threads, thread synchronization, thread events, critical
sections, thread prioritizing, locking, and monitoring.

We learned in Chapter 2 the relevance of application domains and how they are applied to the .NET
Framework execution environment. These subprocesses provide the operation context and environment that
our managed .NET applications run in. When you start an application, the CLR implicitly provides a single
thread for it and allocates it to the application domain that represents your program. The single thread (and
any future threads) wires up your application to the base OS, in unmanaged space.

However, you can spawn additional threads from your application to handle concurrent operations, and the
CLR also gives programmatic opportunity and ability to create additional application domains.

Managed threads are allowed to operate freely within your application process in its domain, and they are
allowed to move freely between application domains. It is also possible to maintain only one thread in your
application domain and move it between several application domains. This is essentially what the .NET
Framework refers to as its "free−threading model." It is precisely this model, and the power of its
implementation, that requires you to devote a significant effort to a sound threading architecture for critical
concurrent processing applications that need it. In a nutshell, so powerful is the model that "given enough
thread, you can easily hang yourself."

Getting Started with Basic Threading

The central character in the threading model story is the System.Threading.Thread class. Thread objects
extend System.Object but they cannot be further extended by you or me. The instantiation of multiple
Thread objects is demonstrated in Figure 16−3. You can instantiate and put into service as many Threads as
you need to execute any methods in any objects or classes referenced in your application. The threads run
concurrently so any objects that are the target of the threads are processed concurrently with the objects
accessed by other threads. Naturally, if there is only one thread in an application the only object that can be
processing is the one that is the target of the thread.

Figure 16−3: Multiple Thread objects means concurrent processing


The Thread object controls the thread, sets its priority, and monitors its execution status. Think of it as
nothing more than the "worker" I mentioned earlier that you summon and have "run a method" while you go
off and do something else.

Table 16−1 lists the basic members of the System.Threading namespace we will encounter in this chapter.
Of course, there are loads more classes and constructs in the namespace, but they will be tackled in the
advanced threading treatise.

To start a new thread in the application, we must first create a delegate to represent the method to execute.
Then, we pass that delegate to a new instance of the Thread object. That's really all there is to adding

571

You might also like