ConcurrentProgrammingonWindows-SynchronizationandTime资源-CSDN文库

3星 · 超过75%的资源需积分: 9 81 浏览量 2009-04-10 12:31:41 上传评论收藏 1.34MB PDF 举报

资源推荐

资源详情

资源评论

Synchronization and Time

TAT E I S A N important part of any computer system. This point seems so

obvious that it sounds silly to say it explicitly. But state within even a sin-

gle computer program is seldom a simple thing, and, in fact, is often scattered

throughout the program, involving complex interrelationships and different

components responsible for managing state transitions, persistence, and so

on. Some of this state may reside inside a process’s memory—whether that

means memory allocated dynamically in the heap (e.g., objects) or on thread

stacks—as well as ﬁles on-disk, data stored remotely in database systems,

spread across one or more remote systems accessed over a network, and so

on. The relationships between related parts may be protected by transactions,

handcrafted semitransactional systems, or nothing at all.

The broad problems associated with state management, such as keeping

all sources of state in-synch, and architecting consistency and recoverabil-

ity plans all grow in complexity as the system itself grows and are all

traditionally very tricky problems. If one part of the system fails, either

state must have been protected so as to avoid corruption entirely (which is

generally not possible) or some means of recovering from a known safe

point must be put into place.

While state management is primarily outside of the scope of this book,

state “in-the-small” is fundamental to building concurrent programs. Most

Windows systems are built with a strong dependency on shared memory due

to the way in which many threads inside a process share access to the same

Duffy_ch02.qxd 9/30/08 6:10 PM Page 13

virtual memory address space. The introduction of concurrent access to

such state introduces some tough challenges. With concurrency, many parts

of the program may simultaneously try to read or write to the same shared

memory locations, which, if left uncontrolled, will quickly wreak havoc.

This is due to a fundamental concurrency problem called a data race or often

just race condition. Because such things manifest only during certain inter-

actions between concurrent parts of the system, it’s all too easy to be given

a false sense of security—that the possibility of havoc does not exist.

In this chapter, we’ll take a look at state and synchronization at a fairly

high level. We’ll review the three general approaches to managing state in

a concurrent system:

1. Isolation, ensuring each concurrent part of the system has its own

copy of state.

2. Immutability, meaning that shared state is read-only and never

modiﬁed, and

3. Synchronization, which ensures multiple concurrent parts that wish

to access the same shared state simultaneously cooperate to do so in

a safe way.

We won’t explore the real mechanisms offered by Windows and the

.NET Framework yet. The aim is to understand the fundamental principles

ﬁrst, leaving many important details for subsequent chapters, though

pseudo-code will be used often for illustration.

We also will look at the relationship between state, control ﬂow, and the

impact on coordination among concurrent threads in this chapter. This

brings about a different kind of synchronization that helps to coordinate

state dependencies between threads. This usually requires some form of

waiting and notiﬁcation. We use the term control synchronization to dif-

ferentiate this from the kind of synchronization described above, which we

will term data synchronization.

Managing Program State

Before discussing the three techniques mentioned above, let’s ﬁrst be very

precise about what the terminology shared state means. In short, it’s any

Chapter 2: Synchronization and Time

Duffy_ch02.qxd 9/30/08 6:10 PM Page 14

state that is accessible by more than one thread at a time. It’s surprisingly

difﬁcult to pin down more precisely, and the programming languages

commonly in use on the platform are not of help.

Identifying Shared vs. Private State

In object oriented systems, state in the system is primarily instance and

static (a.k.a. class) ﬁelds. In procedural systems, or in languages like C++

that support a mixture of object oriented and procedural constructs, state

is also held in global variables. In thread based programming systems, state

may also take the form of local variables and arguments on thread stacks

used during the execution and invocation of functions. There are also sev-

eral other subtle sources of state distributed throughout many layers in the

overall infrastructure: code, DLLs, thread local storage (TLS), runtime and

OS resources, and even state that spans multiple processes (such as mem-

ory mapped ﬁles and even many OS resources).

Now the question is “What constitutes ‘shared state’ versus ‘private

state?’” The answer depends on the precise mechanisms you are using to

introduce concurrency into the system. Stated generally, shared state is any

state that may, at any point in time, be accessed by multiple threads con-

currently. In the systems we care about, that means:

• All state pointed to by a global or static ﬁeld is shared.

• Any state passed during thread creation (from creator to createe) is

shared.

• Any state reachable through references in said state is also shared,

transitively.

As a programmer, it’s important to be very conscious of these points,

particularly the last. The transitive nature of sharing and the fact that, given

any arbitrary pointer, you cannot tell whether the state it refers to has been

shared or not, cause tremendous difﬁculty in building concurrent systems

on Windows. Once something becomes shared, it can be difﬁcult to track its

ownership in the system, particularly to determine precisely at what point

it becomes shared and at what point it becomes unshared in the future (if

at all). These can be referred to as data publication and privatization,

Managing Program State 15

Duffy_ch02.qxd 9/30/08 6:10 PM Page 15

respectively. Certain programming patterns such as producer/consumer

use consistent sharing and transfer of ownership patterns, making the

points of publication and privatization more apparent. Even then it’s easy

to trip up and make a mistake, such as treating something private although

it is still shared, causing race conditions.

It’s also important to note that the above deﬁnitions depend to some

degree on modern type safety. In the .NET Framework this is generally not

negotiable, whereas in systems like C++ it is highly encouraged but can be

circumvented. When any part of the program can manufacture a pointer to

any arbitrary address in the process’s address space, all data in the entire

address space is shared state. We will ignore this loophole. But when

pointer arithmetic is involved in your system, know that many of the same

problems we’ll look at in this chapter can manifest. They can be even more

nondeterministic and hard to debug, however.

To illustrate some of the challenges in identifying shared state, here’s a

class deﬁnition in C++. It has one simple method,

f, and two ﬁelds, one

static

(s_f) and the other instance (m_f). Despite the use of C++ here, the

same principles clearly apply to managed code too.

class C

{

static int s_f;

int m_f;

public:

void f(int * py)

{

int x;

x++; // local variable

s_f++; // static class member

m_f++; // class member

(*py)++; // pointer to something

}

};

The method contains four read/increment/write operations (via C++’s

++ unary operator). In a concurrent system, it is possible that multiple

threads could be invoking

f on the same instance of C concurrently with

one another. Some of these increments will be safe to perform while others

are not. Others still might only be safe if

f is called in certain ways. We’ll see

many detailed examples of what can go wrong with this example. Simply

Chapter 2: Synchronization and Time

Duffy_ch02.qxd 9/30/08 6:10 PM Page 16

put, any increments of shared data are problematic. This is not strictly true

because higher level programming conventions and constructs may actu-

ally prevent problematic shared interactions, but given the information

above, we have no choice but to assume the worst.

By simply looking at the class deﬁnition above, how do we determine

what state is shared? Unfortunately we can’t. We need more information.

The answer to this question depends on how instances of

C are used in

addition to where the

py pointer came from.

We can quickly label the operations that do not act on shared state because

there are so few (just one). The only memory location not shared with other

threads is the

x variable, so the x++ statement doesn’t modify shared state.

(Similar to the statement above about type safety, we are relying on the fact

that we haven’t previously shared the address of

x on the thread’s stack with

another thread. Of course, another thread might have found an address to the

stack through some other means and could perform address arithmetic to

access

x indirectly, but this is a remote possibility. Again, we will assume

some reasonable degree of type safety.) Though it doesn’t appear in this

example, if there was a statement to increment the value of

py, i.e., py++, it

would not affect shared state because

py is passed by value.

The

s_f++ statement affects shared state because, by the deﬁnition of

static variables, the class’s static memory is visible to multiple threads run-

ning at once. Had we used a static local variable in

f in the above example,

it would fall into this category too.

Here’s where it becomes complicated. The

m_f++ line might, at ﬁrst

glance, appear to act on private memory, but we don’t have enough infor-

mation to know. Whether it modiﬁes shared state or not depends on if the

caller has shared the instance of

C across multiple threads (or itself received

the pointer from a caller that has shared the instance). Remember,

m_f++ is

a pointer dereference internally,

(this->m_f)++. The this pointer might

refer to an object allocated on the current thread’s stack or allocated dynam-

ically on the heap and may or may not be shared among threads in

either case.

class D

{

static C s_c; // initialized elsewhere...

C m_c; // also initialized elsewhere...

Managing Program State 17

Duffy_ch02.qxd 9/30/08 6:10 PM Page 17

剩余63页未读，继续阅读

评论收藏

内容反馈

Shane06

2013-05-15

不是很全的电子书
qq1302003035

2012-06-09

Thank you, but it is not completed

cuiweifu

粉丝: 10
资源: 24

Concurrent Programming on Windows - Synchronization and Time

最新资源

Concurrent Programming on Windows - Synchronization and Time

Concurrent programming on windows

Concurrent Programming on Windows

concurrent programming on windows

Concurrent Programming on Windows 无水印pdf

Windows并发编程指南 Concurrent Programming on Windows (english)

Windows并发编程指南 Concurrent Programming on Windows (english)part2

Windows并发编程指南 Concurrent Programming on Windows (english)part3

Concurrent, Real-Time and Distributed Programming in Java: Threads, RTSJ and RMI

Concurrent and Real-Time Programming in Java

Concurrent, Real-Time and Distributed Programming in Java Threads, RTSJ 无水印原版pdf

Multiprocessor+Systems-on-Chips

UNIX Network Programming Volume 2(Unix网络编程卷2英文版)

Object-Oriented Software Construction 2nd

python3.6.5参考手册 chm

Concurrent_and_Real-Time_Programming_in_Java.rar_java programmin

Concurrent.and.Real.Time.Programming.in.Java.eBook-LiB.chm

Thinking in Java 4th Edition

深入理解计算机系统（英文版）

[Go语言入门（含源码）] The Way to Go (with source code)

The way to go

SystemVerilog Reference Manual 3.1a（中英文版）+最新SV IEEE 标准

ILSpy 安装包和压缩包

DevExpress22.X完美Patch资源

基于C#与Sql Server的智慧星学生选课管理系统.rar

CefFlashBrowser - Flash浏览器

最新资源