JPH0423137A - Thread generation system and parallel processing system - Google Patents

Abstract

PURPOSE:To generate threads at a high speed by storings thread control table for ended threads and a stack and then reusing the stored information when the threads are generated within a same process. CONSTITUTION:A shared memory 53 stores the processes 1-1 - 1-2. In a process 1-1, for example, the threads 2-1 - 2-3 read and write the data 422-1 while executing a program 421-1. The threads that finished each processing are returned to an assembly 36 of idle threads and also added to an assembly 32-1 or 32-2 of the finished threads included in a process. If the threads are included in the assembly 32-1 when the threads are generated in a process, the threads of the assembly 32-1 are used. These threads have the small parts to be initialized on a thread control table and the stacks allocated with the memories. Thus the threads can be generated at a high speed.

Description

[Detailed Description of the Invention] C Industrial Field of Application] The present invention provides a process that has a plurality of threads that share programs and data and each have a stack, a program counter, and a register, within a process that has its own virtual space. The present invention relates to a thread generation method in an operating system that executes multiple program flows in parallel.

It is particularly suitable for an operating system of a system in which a plurality of threads are processed in parallel by a multiprocessor.

[Conventional technology]

In Section 6 of Panasequent's Parallel Programming Training Materials (for C language), 1nfork() is explained as a function that executes subprograms in parallel. In that description, at the beginning of the application mfor
It is shown that when k() is called, a child process is generated, but from the second time onwards, the child process generated by the first mfork() is reused. According to this, it is possible to speed up the generation of processes from the second time onward.

Conventionally, it has been said that when performing parallel processing in a multiprocessor, it is important to quickly generate a process as a unit of processing in order to improve performance. This is because even if the time to execute an application program is greatly reduced by parallel processing, if it takes time to generate a process, overall performance will not improve.

The method in the above document shows a method for speeding up process generation itself. However, since the switching speed of processes is slow, it is impossible to quickly share work for parallel processing as long as processes are used. In other words, even if the generation time is shortened, process switching is required to execute the generated process, and if this is slow, no effect will be obtained.

Therefore, in recent years, threads that can switch quickly have attracted attention. In order to switch between processes, each process has its own virtual space.

It took time to switch between virtual spaces.

The idea of threads is to separate a conventional process into an execution environment, which is a unit for allocating resources such as virtual space and files, and a unit called a thread, which is a unit of CPU allocation or control flow.

Threads have individual stacks and registers, but they share virtual space (which includes programs and data). Therefore, switching between threads within the same process can be performed quickly without the need to switch virtual spaces.

[Problem to be solved by the invention]

The method of reusing a process in the literature described in the above-mentioned prior art describes a method of reusing a process that has its own virtual space, and does not consider reusing threads that share a virtual space. Further, in the method of this document, a process that has completed processing is made to wait in a spin state, that is, a running state, which results in wasteful use of the processor.

An object of the present invention is to provide a method for speeding up the creation of threads that share a virtual space by reusing thread management tables and stacks of terminated threads.

Another object of the present invention is to save a thread management table of terminated threads for each process, and reuse the saved thread management table when creating a thread within the same process. The purpose of this invention is to provide a method that allows thread management tables to be preempted and used for use by other processes when there is a shortage of free thread management tables when creating threads at high speed.

Another object of the present invention is to save the stack area of terminated threads, and when creating threads in the same process, reuse the saved stack to speed up the creation. The purpose is to provide a method to save and release the stack area when there is insufficient memory during generation.

Another object of the present invention is to save thread management tables and stacks of terminated threads, and when creating threads within the same process, by reusing certain saved information to create threads. The objective is to improve the cache hit rate of accesses to the thread management table and stack.

[Means for resolving lesson order]

To achieve the above objective, the thread management table and stack of terminated threads are saved and managed for each process, and when a thread is generated again within that process, the saved information is reused.

As mentioned above, the thread management tables and stacks of threads that have terminated are managed for each process, but when the system as a whole runs out of thread management tables and memory, the thread management tables and stacks saved for other processes can be You can steal the stack.

[Effect]

Each thread management table includes a pointer that indicates the stack area used by the thread, a pointer that forms a list of management tables of threads that have terminated for each process,
Contains pointers forming a list of unused and free thread management tables.

A pointer that indicates the stack area allows correspondence between the thread management table and the used stack area.

Furthermore, since one thread management table can be connected to the save list for each process and the table list for the entire system at the same time, it is possible to preempt the memory or thread management table when the memory or thread management table is insufficient.

〔Example〕

An embodiment of the present invention will be described in detail below with reference to the drawings.

FIG. 1 is a diagram showing the configuration of the present invention. In FIG. 1, 51-1 to 51-3 are processors, 52 is a bus, and 53
is shared memory, 54-1 to 54-3 are registers, 55-
1 to 55-3 are cache memories, 1-1 to 1-2 are processes, 2-1 to 2-10 are threads, 32-1 to 32
-2 is a set of threads that have ended within the process, 36 is a set of free threads, 4.21-1 to 421-2 are programs, and 4.22-1 to 422-2 are data.

FIG. 1 shows a plurality of processors 51-1 to 51-3 connected to a bus 5.
It is a tightly coupled multiprocessor connected to a shared memory 53 via 2. Shared memory stores information used by the operating system and users. One of them is processes 1-1 to 1-2. A process is a unit of a user's work,
Each has a program and data. Also, each process has one or more threads. A thread is a logical processor with a stack and registers including a program counter and a stack pointer. Threads within the same process share programs and data. In FIG. 1, threads 2-1 to 2-3 read and write data in 4-22-1 while executing all programs 421-1. Parallel processing can be easily achieved if each processor takes part in executing multiple threads.

When a processor executes a scheduling program and determines the next thread to process, it loads the register values of that thread into the processor's registers. Then, the program is executed from the location pointed to by the loaded program counter value. In Figure 1, 51-
1.51-2゜51-3 each processor has T
It can be seen that threads 1, T2° and T3 are being executed.

Process threads can be dynamically created and terminated. When the system is started, all threads are included in the free thread set 36. When creating a thread in a process, the thread is extracted from this set of free threads. However, when a thread is extracted from a set of free threads, it is necessary to initialize a thread management table and allocate stack memory, which takes a relatively long time. In FIG. 1, a mechanism for speeding up thread generation according to the present invention is incorporated. The thread that has completed processing is returned to the set of 36 free threads, and is also added to the set of threads that have completed within the process 32-1 or 32-2. When a thread is created in a process, if the thread is included in the set of terminated threads, that thread is used.

These threads have fewer thread management tables to initialize, and memory is also allocated to the stack. Therefore, threads can be generated quickly. In addition, since these threads have been running until recently, there is a high possibility that the contents of the management table and the contents of the stack are in the cache memories 55-1 to 55-3 of the preset, and access to them is likely to occur at a high cache hit rate. It gets expensive.

FIG. 2 is a diagram showing table management according to the embodiment of the present invention. In FIG. 2, 1-] to 1-2 are process management tables, 2-1 to 2-10 are thread management tables, and 31-1 to 31-2 are pointers indicating a list of threads belonging to the process. , 32-1 to 32-2 are pointers indicating a list of threads that have ended within the process;
33-1 to 33-2 are pointers that form a list of threads to which the process belongs, 34-1 to 34-3 are pointers that form a list of threads that have ended within the process, and 35-1 to 35-3 are empty threads. A pointer 36 forming a management table is a pointer pointing to an empty thread management table.

Each process and thread is managed by a table. The tables for managing processes are process management tables l-1 to 1-2, and the tables for managing threads are thread management tables 2-1 to 2-10. The process management table is a structure, and its members include a pointer 31-1 that points to a list of threads belonging to a process and a pointer 32-1 that points to a list of threads that have ended within the process.

In FIG. 1, threads 2-1 to 2-3 are processes 1-
It belonged to 1. In FIG. 2, the pointer 31-1 of the process management table 1-1 points to the top of the list of thread management tables 2-1 to 2-3.

Further, in FIG. 1, the threads 2-4 to 2-6 that terminated in the process 1-1 are grouped together as a set 32-1. In FIG. 2, a process management table pointer 32-1 points to a list of thread management tables 2-4 to 2-6. The same applies to process 1-2.

In FIG. 1, unused free threads are grouped together by a set 36. In FIG. 2, pointer 36 points to a list of unused thread management tables. The thread management table belonging to list 1 of the free thread management table can also belong to the list of management tables of threads that have ended within the process.

The thread management table is also a structure, and its members have two types of pointers.

One is pointers 33-1 to 33-2 that form a list of threads belonging to the process, and pointers 34-1 to 34-3 that form a list of threads that have ended within the process.
used for. The other is a pointer that forms a list of free thread management tables.

FIG. 3 shows a virtual space in one embodiment of the present invention. In FIG. 3, 40 is the entire virtual space used by the processor, 41 is the system space, and 42-1 to 42-1 are the entire virtual space used by the processor.
42-2 is a user space.

Since the processor has 32 address buses, the size of the virtual space that can be used by the processor is 2'' = 4
That's G bytes. The upper 2G bytes of this virtual space, addresses 2G to 4G, are system space used by the operating system. The process management table and thread management table described in FIG. 2 are stored in this area.

The lower 2 Gbytes of the virtual space, addresses 0 to 2 G, are user space used by user processes. The user space is independent for each process, and the user space of process 1-1 in FIG. 1 is 42-1, and the user space of process 1-1 in FIG.
The user space of 2 is 42-2.

All threads belonging to the same process share the same user space. Thread 2-1 belonging to process 1-1.
2-2.2-3 reads and writes to the user space 42-1.

FIG. 4 is a diagram showing the system space of FIG. 3 in detail. In FIG. 4, 1-1 to 1-2 are process management tables, 2-1 to 2-4 are thread management tables, and 11 is a pointer that indicates a list of free thread management tables. Each process management table is a structure consisting of a plurality of members, and a pointer forming a list of threads belonging to a process and a pointer forming a list of free thread management tables is one member of this structure pair. Further, the virtual space address of the head of the thread table is entered as a pointer indicating these threads.

FIG. 5 shows the relationship between the user space of FIG. 3 and the thread management table. In FIG. 5, 2-1 to 2-4 are thread management tables, 37-1 to 37-4 are pointers pointing to the U area, 38-1 to 38-4 are pointers pointing to the user stack, and 42-1 is a pointer pointing to the user stack. User space, 421-1 is a program, 422-1 is data, 424-1 to 424-4
is a user stack and 425-1 to 425-4 beam areas.

As shown in Figure 3, each process has its own user space. The user space 42-1 in FIG. 5 is the process 1-
1 user space is shown. Each process has a program and data φ. These are placed in user space. In FIG. 5, these are 42]-1 and 422-1. Programs and data are shared between threads within the same process.

On the other hand, a 5U area and a user stack are provided for each thread. The U areas 425-1 to 425-4 are areas for storing data used by the operating system that is necessary only when a thread is running. Its contents include the operating system stack, system call arguments, and register save areas. Among the plurality of U areas within a process, the first one 425-1 stores information regarding the process as well as information regarding the thread. Its contents include the files being used.

The user stack is a stack used during execution of a user program. Each thread must have its own user stack to call subroutines independently.

The members of the thread management table include pointers (37-1 to 37-4 and 38-1 to 38-4, respectively) pointing to the U area and user stack used by the thread.

Although the thread in the thread management table 2-4 has already ended, the U area and user stack area of that thread will not be released while the thread management table is linked to the list of ended threads within the process. The thread management table pointer still points to the U area and user stack that it was using. When the thread management table 2-4 is reused to generate a thread, the U area 425-4 and user stack 424-4 pointed to by the thread management table 2-4 are also reused.

FIG. 6 shows a case where a thread is generated in process 1-1 in the state shown in FIG.
Since there is a thread in the list of finished threads, the first thread 2-4 will be reused to generate a thread. First, in order to remove thread 2-4 from the list of finished threads, pointer 32-1 is made to point to thread 2-5. Next, in order to remove the thread management table from the list of free threads, the pointer 35-2 is also set to slerad 2.
-Change it to point to 5. Then, the freed thread management table 2-4 is connected to the end of the list of processes to be discarded.

FIG. 7 shows a case where the thread 2-2 has finished processing in the state shown in FIG. 2. First, the thread management table 2
-2 from the list of threads belonging to the process, the pointer 33-1 is changed to point to the thread management table 2-3.

Next, insert the removed table at the beginning of the list of terminated threads. For this purpose, the pointer 32-1 points to the table, and the table pointer 33-2
points to the thread management table 2-5. The table is inserted at the beginning of the list so that the management table and stack of the most recently terminated thread can be reused when creating a thread. This is because if the thread belongs to a thread that has been executed until recently, there is a high possibility that its contents are stored in the cache memory.

You will also need to add this table to the list of free threads, making sure to connect to the end of the list. This is to prevent threads connected to the terminated thread list from being used to create threads for other processes. In the figure, the pointer 35-6 of the thread 2-9 has been changed to point to the thread management table 2-2.

Figure 8 shows the new process 1-3 in the state of Figure 2.
This shows the case where a thread is created and a thread is created within it. If the process is new, no thread management table is connected to the end thread list 32-3 of the process.

Therefore, when generating a thread, the thread management table is retrieved from the list 36 of free thread management tables. When taking out the table, the first table in the list is taken out, and therefore the pointer 36 is changed to point to the thread management table 2-8. Next, the retrieved table is stored in the thread list 31-3 belonging to the process.
Add to.

FIG. 9 shows a case where another thread is created in the process 1-3 in the state shown in FIG. In this case, as in the case of FIG. 8, the list of terminated threads is empty, so a table is taken out from the list of free thread management tables. Similarly, an attempt is made to retrieve a table from the top of the list, but the thread management table 2-8 at the top also belongs to the list of terminated threads of other processes. Therefore, it is necessary to remove the thread management table from the list of terminated threads. It is then added to the list of threads belonging to the process.

FIG. 10 shows an algorithm for generating threads. First, in step 61, it is checked whether the list of terminated threads of the process for which a thread is to be generated is empty. If it is not empty, the thread management table is removed from the head of the list of terminated threads at 65, and added to the list of threads belonging to the process at 66 for use.

If the list is empty in step 61, a thread management table is taken out from the top of the list of free thread management tables and used in step 62. However, if the thread management table in 63 belongs to the end thread list of another process, it is necessary to remove the table from the list as in 64. The removed table is added to the list of threads belonging to the process, again at 66.

FIG. 11 is an algorithm for terminating a thread. First, in step 67, the management table for that thread is removed from the list of threads belonging to the process.

Next, in 68, the table is inserted at the beginning of the list of terminated threads of the own process. Further, the table is also connected to the end of the list of free threads as shown in 69.

FIG. 12 shows a time chart when a parallel processing program is executed using the present invention.

Time flows from left to right. As shown in 71, only thread To is initially being executed. T at 72.

are threads Tl, T2. Generate T3. In this generation, the thread management table is extracted from the free thread list, and TO to T3 are processed in parallel, respectively 73-1 to 73-4.
Execute. The processing from T1 to T3 ends at steps 74-2 to 74-4. These thread management tables are linked to the process's list of termination threads. At 75, only To is executed. When threads are generated again in 76, the threads connected to the list of finished threads are reused, so generation is fast, and parallel processing in 77-1 to 77-4 can be efficiently executed. In a parallel processing program that repeatedly creates and terminates threads,
By using the present invention, the second and subsequent generation can be performed at high speed.

〔Effect of the invention〕

According to the present invention, since the management table and stack of a previously executed thread can be reused when generating a thread, thread generation can be sped up.

In addition, according to the present invention, thread generation can be sped up, so a parallel processing program that repeatedly generates and terminates threads can be efficiently executed. Since the thread management table and stack of the thread management table and stack can be reused, the cache hit rate for accessing them can be improved.

[Brief explanation of the drawing]

Fig. 1 is a diagram showing an overview of the present invention, Fig. 2 is a table configuration diagram, Fig. 3 is a diagram showing a virtual space map, Fig. 4 is a diagram showing a system space map, and Fig. 5 is a diagram showing a user space. A diagram of the relationship between and thread management table. Figure 6 is a diagram showing table operations when a thread is created, Figure 7 is a diagram showing table operations when a thread is terminated, and Figure 8 is a diagram showing table operations when a process is created. , Figure 9 is a diagram showing the operation of the table when another thread is created in the new process of Figure 8, Figure 10 is a diagram showing the algorithm when creating a thread, and Figure 11 is a diagram showing how to terminate the thread. FIG. 12 is a diagram showing a time chart when a parallel processing program is executed using the present invention. 1-1 to 1-3...process, 2-1 to 2-10...
- Threads, 31-1 to 31-3...Pointers indicating a list of threads belonging to the process, 32-1 to 32
-3... Pointer indicating the list of terminated threads,
33-1 to 33-3 and 34-1 to 34-3... Pointers forming a list of threads belonging to a process or a list of terminated threads, 35-1 to 35-6... Forming a list of free threads. Pointer to point to, 36... Pointer to point to list of free threads, 37-1 to 37
-4... Pointer pointing to U area, 38-1 to 38-
4... Pointer pointing to user stack, 40... Virtual space, 41... System space, 42-1 to 42-2.
... User space, 51-1 to 51-3... Processor, 52... Bus, 53... Shared memory, 54-1 to 5
4-3...Register, 55-1 to 55-3...Cache, 61 to 66...Processing for thread generation,
67-68...Processing for thread termination, 71 and 73
-1 to 73-4 and 75 and 77-1 to 77-4...thread execution, 72 and 76...thread generation, 74-
2 to 74-4... End of thread, 421-1 to 42
1-2...Program, 422-1 to 422-2...Data. 1 to 424-4...User stack, Figure 4, Figure 5, Figure 6, Figure 7, Figure 8, Figure 9, Figure 10, Figure 11.

Claims (1)

[Claims] 1. One or more processes operate under one operating system, and each process has multiple threads that share programs and data and have their own registers and stacks. In a thread generation method for a computer system that can execute multiple program flows in parallel, the thread management table and stack of a thread that has finished execution are saved, and when a thread is generated again in the same process, the thread management table and stack are saved. A thread generation method characterized by using a management table and a stack of the thread. 2. One or more processes run under one operating system, each of which has multiple threads that share programs and data, has its own registers and stacks, and has multiple program flows. In a thread creation method for a computer system that can execute threads in parallel, when the stack of a thread that has finished execution is reduced and saved, and a thread is created again within the same process,
A thread generation method characterized by using the saved reduced stack. 3. According to claim 1 or 2, when a thread is created in a process for which there is no thread management table stored, an empty thread management table that does not belong to any process is stored in the system. A thread generation method characterized by the ability to use a table of threads stored for other processes when one is not available. 4. According to claim 1 or 2, the cache hit rate of access to the thread management table and stack is improved by using the stored thread management table and stack. Thread generation method. 5. On a computer with multiple processors, in a parallel processing method where multiple threads are generated within one process and each of the multiple threads is executed by multiple processors, a parallel part of the program is used. When a thread is generated in front of the program to distribute processing, the generated thread is terminated when the processing of the parallel part is completed, and the above thread generation and termination are repeated in the parallel part of the program thereafter. The parallel processing system is characterized in that information about threads that have completed once is saved, and the saved information is used in subsequent thread generation to speed up thread generation and improve processing efficiency. Processing method.