pcxx_ug (1158314), страница 3
Текст из файла (страница 3)
If a TEClass member function is invoked by one of the processor object threads, it is asequential action by that thread. (Hence, there is no way to generate nested parallelismwith this mechanism.) Each thread may see the same scope of variables that an ordinary class member functioncan see. However, there is a major dierence between a TEClass object and a regularclass object.
An ordinary class member function can read and modify any global variables visible from the scope of its declaration. However, in the case of TEClass objects,member functions cannot modify the \global" variables in the program dened outsidethe scope the TEClass declaration.The invocation of a TEClass member function by the main control thread is the mechanism for transferring control from the main thread to the worker threads dened by aProcessors class used to create the TEClass object. While a worker thread is in executionof a member function, it can only see the data members of that TEClass object instanceand the program global variables that are visible from the scope of the TEClass denition.Figure 1 gives an illustration of the multithreaded runtime model that the user should havein mind when programming with TEClass objects.7globalsfloat x;int y[100];cmain(){Processors P;TEClass C c(P);czmain beginsthreads allocatedthread environment objects allocatedcczzthread 0zthread 2thread 1c.foo()c.foo()TEClass C{int z;void foo( );};xythread 3begin parallel executionc.foo()c.foo()c.foo()Barrier−main continuesFigure 1: Multithreads and TEClassTo understand this control ow and these visibility rules, it is best to consider a simple example.
The code below denes a simple thread environment class and the memberfunctions that access it.int my_global;float a_global_array[3];TEClass C{int x, y[100];public:int i;void f(int j){ i = j; }};main(){Processors P;C myThreadEnv(P);myThreadEnv.f(2);}In this case the main thread denes a set of processor object threads called P. The threadenvironment object, myThreadEnv is next allocated. This object is actually a set of instancesof objects dened by the class you would get if you replaced the key word TEClass by class.The constructor calls this with the processor object P, so there is one instance of an object8which contains one copy of an integer variable x and one copy of an array y[100] for eachprocessor object associated with P.The constructor for this set of objects is executed by each processor object bound to it.While this is taking place, the main thread is suspended.
In our example, there is only adefault constructor, so control returns directly to the main thread.When the main thread continues, it invokes myThreadEnv.f(2). Again, this is a signal forthe processor-object/worker-thread to take over. Each thread executes myThreadEnv.f(2)applied local instance of the TEClass object that was allocate to it. Once the worker threadseach start evaluating a member function of a TEClass object, they are free to call othermember functions, or normal C functions. There are three important restrictions that needfurther investigation.1. A processor object, while executing a TEClass member function may read the variablesdeclared in the global scope of the same le, in this case a_global and my_global_array.However, processor thread may NOT MODIFY these global values.2. There are some restrictions on I/O to and from the TEClass member functions.3.
When a TEClass member function returns a value to the main thread it is up to theprogrammer to make sure that this is well dened.We will discuss each of these restrictions and illustrate them with examples.The rst restriction is very important. At rst sight, it may seem strange that a processorobject thread cannot modify global variables. However, keep in mind that allowing themto do this can result in complex race conditions. That is, without some form of globalsynchronization mechanisms, there is no way to guarantee that one processor thread willmodify a variable before another processor reads the variable.
Consequently, one cannoteasily predict the behavior of programs that ignore this rule.A second, more pragmatic reason for this restriction is that pC++ is designed to beportable across distributed memory as well as shared memory systems. On distributedmemory machines the global data is duplicated in each processors address space and thecompiler generates SPMD style parallelism for these machines.
If a processor threads wereallowed to make arbitrary changes to global variables, there is no way for the compiler tomake sure they maintain a consistent state across address spaces. (This is because it isnot possible to completely solve the problems associated with aliases caused by pointers inC.) To get around this problem, the main thread is the only one that is allowed to modifythese variables. Because, in an SPMD execution environment, the main thread is duplicatedacross process, it is a much easier task to make sure that the main thread is identical oneach processor.To see this restriction in more detail consider these casesint a, b;int foo(){a++; }9int bar(int *p){ *p = 0; }TEClass C{public:int x;void f(int *z){foo(); //<<< error: modifies global statebar(z); // may be o.k.}};main(){ProcessorsC T(P);foo();T.f(&a);T.f(&T.x);}P;// o.k.//<<< error: because bar will modify a// o.k.In this case the function foo() can be called from the main program, but not from aTEClass member function because it modies a global variable.
However, the call to T.f()is problematic. In one case, it is an error because it calls bar() with the address of a globalvariable and in the other case it operates on a member eld of the TEClass instance hencethe call T.f(&T.x) is valid.Perhaps the most perplexing rule associated with TEClass objects has to do with valuesreturned to the main control thread. When a TEClass method is invoked by a processorthread, it behaves exactly like any other class member function.
However, when a TEClassmember function is invoked by the main thread the action is dierent. Each processor objectthread executes the function and each will return a value. Unfortunately, the calling threadis only expecting a single value to be returned. To avoid non-determinism in the programthe programmer is required to make sure these values are all identical.To illustrate this consider the following simple example.
We will use two special pC++intrinsics. MyProc() is a function that may be called by a processor object thread to determine its \thread identier" which is a value between 0 and p-1 where p is the number ofprocessor threads that are allocated in a processors object. (In version 1.0 of pC++, thiscorresponds to the processor number that the thread is assigned to.)The second function pCxx_max() is a pC++ intrinsic function that selects the maximumof a set of values from each of the processor threads. (This function is a member of a largerfamily of special TEClass reduction functions that will be described in greater detail below.)The example illustrates both the correct and incorrect use of the TEClass member function return mechanism.TEClass C{10public:int f(){ return MyProc(); }int g(){int y = f(); //<<< call to f o.k.return pCxx_max(y);}};main(){Processors P;C MyThreads(P);int x = MyThreads.f(); //<<< error.
multiple return values for f.int max_thread_id = MyThreads.g(); //<<< o.k.}In this example, the function f() returns a dierent value for each processor objectthread. Consequently, it does not make sense to call it from the main thread. However, itsmeaning as a scalar valued function is well dened within the individual thread environments:it simply returns the identier of that thread. On the other hand, the function g() uses thepCxx_max() reduction to select the largest value returned by each of the calls to f() as areturn value, so each thread object returns the same value.Note that there are several alternative designs that pC++ could have used that wouldavoid this \single value return value" restriction.
First, one could stipulate that the mainthread would \pick" a value at random from the set of values generated on each thread.However, experience has shown us that users rarely want this feature. In addition, thisscheme is non-trivial to implement. Alternatively, one could devise a mechanism that wouldallow sets of values to be returned and assigned to scalar variables just like a scalar returnvalue. Unfortunately, this would violate the C++ type system.
However, pC++ does providea way to create and manipulate aggregate values and this topic is discussed in the chapteron Collections.3.2.1 Thread Reduction Functions. Ver. 2.0The most common use of returning a single value to the main control thread is to reduce, orsummarize, the information computed by each thread of a processor object. Each of thesefunctions are primitive, \built in", member functions of TEClass objects. In addition tocomputing and returning a uniform value to each processor object thread, they provide away to synchronize the computations of each thread.
The reduction functions available inpC++ are summarized in the table below. They are described in terms of a data type Twhich is assumed to have operators >, ==, >=, +, * which obey an associativity law. Tmay be a standard base type like int or double, or it may be a user dened type subjectto some simple restrictions which we will describe later.
T pCxx_max(T x) returns the maximum of a set of thread values.11returns the minimum of a set of thread values.T pCxx_sum(T x) returns the sum of a set of thread values.T pCxx_product(T x) returns the product of a values distributed over a processor set.It is important to understand that these functions require the involvement of every threadin a processor set.
For example, the following code illustrates two attempts to sum a set ofvalues over the odd numbered threads of a TEClass object.T pCxx_min(T x)TEClass C{float x;float oddSum(){if(MyProc()/2 != 0)//<<< error: only odd threadsreturn pCxx_sum(x); //<<< are executing this lineelse return 0;}float tryAgain(){float y;if(MyProc()/2 != 0) y = x; else y = 0;return pCxx_sum(y);}};In the rst attempt, oddSum(), only the odd numbered threads execute the sum reduction.Consequently, they will \hang" waiting for the even numbered threads to contribute theirpart. In the second case, tryAgain(), all threads execute the reduction and there is noproblem.3.2.2 Communication Between Threads. Ver.
2.0Because one of the reasons for introducing TEClass structures into pC++ was to allowSPMD style computation to co-exist with the data parallelism, we must also consider theissues related to the portability of SPMD code. Until fairly recently, there have been nostandard ways to make message passing code portable.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
