WO2011118014A1 - 検証支援プログラム、制御プログラム、検証支援装置、マルチコアプロセッサシステム、検証支援方法、および制御方法 - Google Patents

検証支援プログラム、制御プログラム、検証支援装置、マルチコアプロセッサシステム、検証支援方法、および制御方法 Download PDF

Info

Publication number
WO2011118014A1
WO2011118014A1 PCT/JP2010/055290 JP2010055290W WO2011118014A1 WO 2011118014 A1 WO2011118014 A1 WO 2011118014A1 JP 2010055290 W JP2010055290 W JP 2010055290W WO 2011118014 A1 WO2011118014 A1 WO 2011118014A1
Authority
WO
WIPO (PCT)
Prior art keywords
thread
time
execution
target thread
target
Prior art date
Application number
PCT/JP2010/055290
Other languages
English (en)
French (fr)
Inventor
宏真 山内
浩一郎 山下
鈴木 貴久
康志 栗原
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2010/055290 priority Critical patent/WO2011118014A1/ja
Priority to JP2012506731A priority patent/JP5423876B2/ja
Publication of WO2011118014A1 publication Critical patent/WO2011118014A1/ja

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/45Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions
    • G06F8/458Synchronisation, e.g. post-wait, barriers, locks

Definitions

  • the present invention relates to a verification support program, a verification support apparatus, and a verification support method for simulating circuit information. Furthermore, the present invention relates to a control program for controlling thread assignment, a multi-core processor system, and a control method.
  • a semaphore is mentioned as a main method of exclusive control.
  • one CPU Central Processing Unit
  • another CPU operating a thread different from the thread waits for access to the shared data until one CPU releases the lock.
  • the multi-core processor system In the multi-core processor system, a plurality of threads are assigned to each CPU, and if two threads having a data dependency relationship are assigned to different CPUs, the execution timing of the two threads is shifted. For this reason, there is a problem that the execution result when the multi-core processor system is used is different from the execution result when the single-core processor system is used.
  • the present invention automatically prepares a thread that needs exclusive control, so that a semaphore can be prepared only for the thread with the lowest eye required, and spin loop processing
  • An object of the present invention is to provide a verification support program, a verification support apparatus, and a verification support method that can prevent performance degradation of the CPU due to the above.
  • the disclosed verification support program, verification support apparatus, and verification support method are subject to verification using a multi-core processor model including a first core model and a second core model.
  • a multi-core processor model including a first core model and a second core model.
  • the verification support device by automatically identifying a thread that requires exclusive control, a semaphore can be prepared only for the thread with the lowest eye required, and spin loop processing It is possible to prevent the performance degradation of the CPU.
  • FIG. 6 is an explanatory diagram showing a variable life span in a verification target software 300; It is explanatory drawing which shows an example of a data dependence table.
  • 1 is a block diagram showing a hardware configuration of a verification support apparatus according to a first exemplary embodiment; 3 is a block diagram illustrating a functional configuration of a verification support apparatus 600.
  • FIG. It is explanatory drawing which shows the example by which the verification object software 300 is simulated using the multi-core processor system.
  • FIG. 10 is an explanatory diagram illustrating an example in which a target thread 802 is executed after being delayed.
  • FIG. 10 is an explanatory diagram illustrating an example 1 in which a delay time for delaying a target thread 802 increases.
  • FIG. 10 is an explanatory diagram illustrating an example 2 in which a delay time for delaying a target thread 802 increases.
  • 10 is a flowchart illustrating an example of a verification processing procedure performed by the verification support apparatus 600.
  • 13 is a flowchart showing a detailed description of the specifying process (step S1207) shown in FIG.
  • FIG. 13 is a flowchart showing a detailed description of the specifying process (step S1208) shown in FIG.
  • FIG. 16 is an explanatory diagram illustrating an example of a thread management table 1600 illustrated in FIGS. 12 and 15.
  • FIG. 4 is an explanatory diagram illustrating a hardware configuration of a multi-core processor system according to a second embodiment. It is a block diagram which shows the functional structure of the scheduler 1721 concerning Embodiment 2.
  • FIG. FIG. 11 is an explanatory diagram illustrating a first example of thread A allocation by a scheduler 1721; It is explanatory drawing which shows the example in which the thread
  • FIG. 16 is an explanatory diagram of a second example of thread A allocation by the scheduler 1721. 10 is a flowchart showing a control processing procedure by a scheduler 1721.
  • a thread is an execution unit of processing performed in an application.
  • FIG. 1 is an explanatory view showing an embodiment of the present invention.
  • the verification target software is simulated using the multi-core processor system model and the thread 102 generated from the thread 101 is executed in multi-thread processing on the same processor model will be described as an example.
  • the initial values for variables a to e are as follows.
  • Thread 101 is assigned to one CPU model.
  • the verification support apparatus stores the execution result in an accessible storage device, and compares the first execution result with the second execution result of the thread 101 when the thread 102 is executed with a delay. Use.
  • the verification support apparatus detects the generation of the thread 102, and one of the multi-core processors to which the parent thread is assigned. A thread generated is assigned to another CPU model different from the CPU model.
  • the verification support apparatus applies a load to the thread 102.
  • the verification support apparatus determines whether or not the first execution result and the second execution result stored in the storage device match.
  • the value of the variable e differs between the first execution result and the second execution result, it is determined that they do not match. If it is determined that they do not match, the verification support apparatus outputs that the thread 101 is a thread that requires exclusive control.
  • a thread that requires exclusive control means that exclusive control is required for data that has a dependency relationship between threads. In FIG. 1, the data having a dependency relationship between threads is a variable a.
  • FIG. 2 is an explanatory diagram showing circuit information related to the multi-core processor system model.
  • the circuit information 200 is a model for ESL (Electronic System Level).
  • ESL Electronic System Level
  • each CPU model of a multi-core processor system model including a multi-core processor model, a connection relationship between the CPU models, and the like are represented by a hardware description by SystemC and XML (Extensible Markup Language) scripts.
  • the ESL technology is a high-speed simulation technology in the system upstream process design in which the design of the system LSI is performed while changing the detail (abstraction) at each stage.
  • high-speed operation can be performed by appropriately skipping and concealing detailed clock operations.
  • ESL technology is used as a simulation environment in which software operation is possible by linking with an instruction simulator of a CPU.
  • ESL technology is used for large-scale system LSI (Large Scale Integrated) development such as SoC (System on a Chip).
  • the circuit information 200 includes a first CPU model 201, a second CPU model 202, and a shared memory model 204. Each component is connected via a bus model 203. Each of the first CPU model 201 and the second CPU model 202 includes a cache and a register. When the verification support apparatus executes the simulation, the first CPU model 201 activates the master OS 211 and the second CPU model 202 activates the slave OS 212.
  • FIG. 3 is an explanatory diagram illustrating an example of verification target software.
  • the verification target software 300 shows an example of a program.
  • the verification support apparatus simulates the verification target software 300 using the multi-core processor system, so that the process (thread) coded in the verification target software 300 is changed to the first CPU model 201 (or the second CPU model 202). ).
  • a process coded in the verification target software 300 is referred to as a generation thread.
  • the verification support device detecting the generation instruction of the target thread from the generation source thread is, for example, detecting “pthread_create ();”.
  • a thread generated by “pthread_create ();” from the generation thread is called a target thread.
  • the compiler can detect whether or not there is a dependency between the generation thread and the target thread. Next, the life span of the variable will be described.
  • FIG. 4 is an explanatory diagram showing the life of variables in the verification target software 300.
  • the life of a variable indicates from where to where a certain variable changes in the verification target software 300.
  • the lifetime of the variable can be detected by the analysis unit of the compiler for the verification target software 300.
  • life span of a variable straddles a thread generation instruction like variable a, there is a dependency between the generation thread and the target thread. That is, by analyzing the life span of the variable by the compiler, it is determined whether or not there is a dependency between the generation thread and the target thread. Furthermore, it is determined whether each thread has a semaphore by analyzing whether the compiler has a semaphore.
  • FIG. 5 is an explanatory diagram showing an example of the data dependence table.
  • the data dependency table 500 is a table indicating whether or not there is a data dependency relationship between a parent thread and a child thread generated by the parent thread, and whether or not a semaphore exists between the parent thread and the child thread. It is assumed that the data dependence table 500 is prepared for each child thread.
  • the data dependency table 500 is stored in a storage device accessible by a computer.
  • FIG. 6 is a block diagram of a hardware configuration of the verification support apparatus according to the first embodiment.
  • the verification support apparatus 600 includes a CPU (Central Processing Unit) 601, a ROM (Read-Only Memory) 602, a RAM (Random Access Memory) 603, a magnetic disk drive 604, a magnetic disk 605, and an optical disk.
  • a drive 606, an optical disk 607, a display 608, an I / F (Interface) 609, a keyboard 610, a mouse 611, a scanner 612, and a printer 613 are provided.
  • Each component is connected by a bus 615.
  • the CPU 601 governs overall control of the verification support apparatus 600.
  • the ROM 602 stores programs such as a boot program.
  • the RAM 603 is used as a work area for the CPU 601.
  • the magnetic disk drive 604 controls the reading / writing of the data with respect to the magnetic disk 605 according to control of CPU601.
  • the magnetic disk 605 stores data written under the control of the magnetic disk drive 604.
  • the optical disk drive 606 controls the reading / writing of data with respect to the optical disk 607 according to the control of the CPU 601.
  • the optical disk 607 stores data written under the control of the optical disk drive 606, and causes the computer to read data stored on the optical disk 607.
  • the display 608 displays data such as a document, an image, and function information as well as a cursor, an icon, or a tool box.
  • a CRT a CRT
  • a TFT liquid crystal display a plasma display, or the like can be adopted.
  • I / F An interface (hereinafter abbreviated as “I / F”) 609 is connected to a network 614 such as a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet through a communication line, and the other via this network 614. Connected to other devices.
  • the I / F 609 manages an internal interface with the network 614 and controls data input / output from an external device.
  • a modem or a LAN adapter can be employed as the I / F 609.
  • the keyboard 610 includes keys for inputting characters, numbers, various instructions, etc., and inputs data. Moreover, a touch panel type input pad or a numeric keypad may be used.
  • the mouse 611 performs cursor movement, range selection, window movement, size change, and the like. A trackball or a joystick may be used as long as they have the same function as a pointing device.
  • the scanner 612 optically reads an image and takes in the image data into the verification support apparatus 600.
  • the scanner 612 may have an OCR (Optical Character Reader) function.
  • the printer 613 prints image data and document data.
  • a laser printer or an ink jet printer can be employed as the printer 613.
  • FIG. 7 is a block diagram illustrating a functional configuration of the verification support apparatus 600.
  • the verification support apparatus 600 includes a detection unit 701, an allocation unit 702, a holding unit 703, an execution control unit 704, a coincidence determination unit 705, a time determination unit 706, a setting unit 707, an adjustment unit 708, and an output.
  • each function (detection unit 701 to output unit 709) causes the CPU 601 to execute a program stored in a storage device such as the ROM 602, the RAM 603, the magnetic disk 605, and the optical disk 607 shown in FIG.
  • Each function is realized by I / F 609 or I / F 609.
  • the detection unit 701 uses the circuit information 200 to detect a target thread generation instruction from the generation source thread assigned to the first CPU model 201 during the simulation of the verification target software 300.
  • the assigning unit 702 assigns the target thread to the second CPU model 202 when the detection unit 701 detects a target thread generation instruction. Note that the generation thread is assigned to the first CPU model 201 and the target thread is assigned to the second CPU model 202. However, the target thread and the generation thread may be assigned to different CPU models. .
  • the execution control unit 704 executes the target thread after delaying the target thread by a predetermined delay time.
  • the coincidence determination unit 705 includes the first execution result of the generation source thread when the target thread is executed in the single-core / multi-thread environment, and the generation source when the execution thread is delayed by the execution control unit 704. It is determined whether or not the second execution result of the thread matches.
  • the first execution result of the generation thread when the target thread is executed in the single-core / multi-thread environment is the generation thread when the target thread is executed without delay in the model of the multi-core processor system. Is the same as the first execution result. Therefore, the first execution result is an execution result of the generation thread when the target thread is executed without delay.
  • the output unit 709 outputs information indicating that exclusive control is necessary for the target thread when it is determined that the first execution result and the second execution result do not match.
  • the holding unit 703 holds the execution state of the generation thread before the instruction for generating the target thread.
  • the time determination unit 706 determines the execution start time of the target thread when the generation is delayed. It is determined whether it is after the end time.
  • the setting unit 707 sets the execution state of the generation source thread held by the holding unit 703 when the time determination unit 706 determines that the execution start time of the target thread is not after the generation end time of the generation thread.
  • the adjustment unit 708 increases the predetermined delay time by a predetermined time. Then, the execution control unit 704 executes the generation source thread after setting by the setting unit 707 and executes the target thread after delaying the target thread by a predetermined delay time lengthened by the adjustment unit 708.
  • the coincidence determination unit 705 determines whether or not the first execution result matches the second execution result.
  • the output unit 709 outputs information indicating that exclusive control is not necessary for the target thread.
  • the setting unit 707 executes the execution state of the generation thread that holds the execution state of the generation thread. Set to.
  • the adjustment unit 708 shortens the predetermined delay time by a predetermined time.
  • the execution control unit 704 executes the generation thread after the setting by the setting unit 707 and executes it after delaying the target thread by a predetermined delay time shortened by the adjustment unit 708.
  • the coincidence determination unit 705 determines whether the second execution result of the generation thread matches the first execution result when the execution control unit 704 executes the target thread with a predetermined delay time shortened. Judge whether or not.
  • the output unit 709 uses the shortened predetermined delay time as the delay possible time, and the target thread needs exclusive control.
  • the delay time is associated with the information and output.
  • FIG. 8 is an explanatory diagram showing an example in which the verification target software 300 is simulated using a multi-core processor system.
  • the generation thread 801 coded in the verification target software 300 is assigned to the first CPU model 201 and executed. Specifically, for example, the CPU 601 detects (1) a generation instruction of the target thread 802 from the generation thread 801 coded in the verification target software 300.
  • the CPU 601 when the CPU 601 detects a generation instruction for the target thread 802, the CPU 601 determines whether the target thread 802 and the generation source thread 801 have a dependency relationship based on the data dependency table 500. When it is determined that the target thread 802 and the generation thread 801 have a dependency, the CPU 601 determines whether the target thread 802 has a semaphore based on the data dependency table 500. When it is determined that there is no semaphore in the target thread 802, the CPU 601 allocates (2) the target thread 802 to the second CPU model 202. Specifically, for example, the CPU 601 stores the execution state of the generation thread 801 of the instruction immediately before the generation instruction of the target thread 802. Here, specifically, the execution state is, for example, the value of each variable and the execution position on the verification target software 300.
  • FIG. 9 is an explanatory diagram illustrating an example in which the target thread 802 is executed after being delayed.
  • a predetermined delay time to be delayed in advance is defined, and the CPU 601 delays the execution of the target thread 802 by the predetermined delay time.
  • the predetermined delay time is DELAY and the predetermined time is DEL.
  • DEL 1 [ ⁇ s].
  • DELAY DEL
  • the target thread 802 is assigned to the second CPU model 202, and is executed with a delay of DELAY.
  • the CPU 601 finishes executing the generation thread 801 and the target thread 802, the first execution of the generation thread 801 when the target thread 802 is executed from the storage device in the single-core / multi-thread environment. Get the result.
  • the first execution result of the generation source thread 801 when the target thread 802 is executed without delay is the same as the first execution result shown in FIG. 1, and the RAM 603 and the magnetic disk 605 are the same.
  • the data is stored in a storage device such as the optical disk 607.
  • the CPU 601 determines whether or not the second execution result obtained by executing the target thread 802 after being delayed matches the acquired first execution result.
  • the first execution result and the second execution result are shown below. Here, it is determined that the first execution result and the second execution result match.
  • the CPU 601 indicates that the execution start time of the target thread 802 is after the execution end time of the generation thread 801. Determine whether or not. For example, the CPU 601 stores the execution start time and execution end time of each thread in a storage device such as the RAM 603, the magnetic disk 605, and the optical disk 607 at the time of execution and at the end of execution. Here, the CPU 601 determines that the execution start time of the target thread 802 is not after the execution end time of the generation thread 801.
  • the CPU 601 jumps the instruction position of the first CPU model 201 to the execution position of the saved execution state. Then, the CPU 601 changes each variable stored in the cache of the first CPU model 201 to each variable of the saved execution state.
  • the CPU 601 executes the generation thread 801 and executes it after delaying the target thread 802 by DELAY. Then, for example, when the execution of the generation thread 801 and the target thread 802 ends, the CPU 601 acquires the first execution result from the storage device.
  • the first execution result and the second execution result are shown below.
  • the CPU 601 determines whether or not the execution start of the target thread 802 is earlier than the execution end of the generation thread 801. Determine whether.
  • the CPU 601 changes DELAY until it is determined that the execution start time of the target thread 802 is after the execution end time of the generation thread 801. The process of increasing and delaying execution of the target thread 802 is repeated.
  • FIG. 11 is an explanatory diagram illustrating Example 2 in which the delay time for delaying the target thread 802 is increased.
  • the CPU 601 executes the generation thread 801 and executes it after delaying the target thread 802 by DELAY.
  • the first execution result and the second execution result are shown below.
  • the CPU 601 outputs that the target thread 802 needs a semaphore.
  • the target thread 802 and the verification target software 300 may output the line number of the target thread 802 together.
  • the output format include display on the display 608, print output to the printer 613, and transmission to an external device via the I / F 609. Further, it may be stored in a storage device such as the RAM 603, the magnetic disk 605, and the optical disk 607.
  • FIG. 12 is a flowchart illustrating an example of a verification processing procedure performed by the verification support apparatus 600.
  • the verification support apparatus 600 executes the verification target software (step S1201), and determines whether or not the detection unit 701 detects a generation instruction of the target thread from the executing thread (generation source thread) (step S1201). S1202).
  • the verification support apparatus 600 determines that the generation instruction for the target thread is not detected (step S1202: No)
  • the process returns to step S1202.
  • the verification support apparatus 600 determines that the target thread generation instruction has been detected (step S1202: Yes)
  • a safe thread is a thread that does not require a semaphore.
  • step S1203 If the verification support apparatus 600 determines that the target thread is registered as a safe thread or that a semaphore is necessary (step S1203: Yes), the target thread is assigned to an arbitrary CPU model and the target thread is executed. (Step S1204), it is determined whether or not the verification target software is terminated (Step S1205). When the verification support apparatus 600 determines that the verification target software has not ended (step S1205: No), the process returns to step S1202.
  • step S1203 determines that the target thread is not registered in the safe thread and it is not determined that the semaphore is necessary (step S1203: No)
  • the dependency relationship between the target thread and the generation thread is determined. It is determined whether or not there is a semaphore (step S1206).
  • step S1206 determines that there is no dependency between the target thread and the generation thread or there is a semaphore. If the verification support apparatus 600 determines that there is no dependency between the target thread and the generation thread or there is a semaphore (step S1206: No), the process proceeds to step S1204. On the other hand, when the verification support apparatus 600 determines that the target thread and the generation thread have a dependency and there is no semaphore (step S1206: Yes), a specific process is executed (step S1207 (or step S1208)). Return to step S1201.
  • step S1205 determines in step S1205 that the verification target software has ended (step S1205: Yes), the series of processing ends.
  • FIG. 13 is a flowchart showing a detailed description of the specifying process (step S1207) shown in FIG.
  • the verification support apparatus 600 uses the holding unit 703 to store the execution state of the generation thread of the instruction immediately before the generation instruction of the target thread (step S1301). Then, the verification support apparatus 600 assigns the target thread to a CPU model different from the generation thread by the assignment unit 702 (step S1302).
  • the verification support apparatus 600 causes the match determination unit 705 to execute the target thread with a delay from the first execution result of the generation thread when the target thread is executed in the single-core / multi-thread environment. It is determined whether or not the second execution result of the generation thread of the same matches (step S1305).
  • DELAY is increased, but the verification support apparatus 600 sets a value larger than the execution time of the generation thread to DELAY, and whether or not the first execution result matches the second execution result. It may be determined whether or not a semaphore is necessary.
  • FIG. 14 is an explanatory diagram showing an example of the thread management table 1400 shown in FIGS. 12 and 13.
  • the verification target program has a data dependency between the parent thread and the child thread, and each thread without a semaphore is either a safe thread that does not require exclusive control or a thread that requires exclusive control. It is registered in Crab.
  • thread C and thread D are registered as safe threads
  • thread A is registered as a thread that requires exclusive control.
  • the designer of the verification target software knows the thread that needs exclusive control, and can put it into the verification target software so that exclusive control is performed only on the minimum necessary shared data. . Thereby, spin loop processing can be reduced and the throughput of the CPU can be improved.
  • FIG. 13 shows whether or not exclusive control is necessary for the target thread. However, if the delay time is short, the exclusive control may not be necessary. Therefore, the delay time that does not require exclusive control is specified as the delay possible time. The processing procedure is shown in FIG.
  • FIG. 15 is a flowchart showing a detailed description of the specifying process (step S1208) shown in FIG.
  • Step S1501 to step S1505 and step S1508 to step S1511 in FIG. 15 are the same as step S1301 to step S1305 and step S1307 to step S1310 in FIG.
  • the verification support apparatus 600 outputs to the thread management table 1600.
  • the delay possible time is specified by increasing DELAY, but a large value is entered in DELAY beforehand, and the delay from DELAY when the first execution result and the second execution result do not match
  • the possible delay time may be specified by decreasing the time.
  • the verification support apparatus 600 can specify the delayable time by repeating the decrease and re-execution of DELAY until the first execution result matches the second execution result.
  • the thread management table 1600 will be described with reference to FIG.
  • FIG. 16 is an explanatory diagram showing an example of the thread management table 1600 shown in FIG. 12 and FIG.
  • each thread having a data dependency relationship between a parent thread and a child thread and having no semaphore is registered as either a safe thread that does not require exclusive control or a thread that requires exclusive control.
  • the thread C and the thread D are registered as safe threads, and a thread that requires exclusive control includes a thread name, a thread having a dependency relationship with the thread indicated by the thread name, and a delay possible time. It is registered. It is indicated that the thread A is registered as a thread that requires exclusive control, the thread B and the data have a dependency, and the delay possible time is 99 [ ⁇ s]. Note that when 0 is registered as the delay possible time, the delay cannot be delayed, so that the semaphore needs to be locked.
  • the scheduler can specify a thread that needs exclusive control by using the thread management table 1600, and can determine whether to lock dynamically by referring to the delay possible time.
  • the multi-core processor is a processor in which a plurality of cores are mounted. If a plurality of cores are mounted, a single processor mounted with a plurality of cores or a processor group in which single-core processors are arranged in parallel may be used. In the second embodiment, in order to simplify the description, a processor group in which single-core processors are arranged in parallel will be described as an example.
  • FIG. 17 is an explanatory diagram of a hardware configuration of the multi-core processor system according to the second embodiment.
  • the multi-core processor system 1700 includes a CPU 1701, a CPU 1702, and a shared memory 1704. Each component is connected by a bus 1703.
  • the CPU 1701 and the CPU 1702 each have a cache, a register, and a core.
  • An OS 1711 which is a master OS operates on the CPU 1701
  • an OS 1712 which is a slave OS operates on the CPU 1702.
  • the OS 1711 includes a scheduler 1721, and the scheduler 1721 determines thread allocation.
  • the shared memory 1704 is a memory shared by the multi-core processors, and stores a boot program such as the OS 1711 and the OS 1712, a program such as application software, a thread management table 1600, and an execution time table 1731.
  • the shared memory 1704 includes a ROM (Read Only Memory), a RAM (Random Access Memory), a flash ROM, and the like.
  • the ROM stores the program and the like, and the RAM is used as a work area for the CPU 1701 and the CPU 1702.
  • the program stored in the shared memory 1704 is loaded on each CPU, thereby causing the CPU to execute a coded process.
  • the execution time table 1731 is a table in which the execution time of each thread is registered.
  • the execution time of each thread can be calculated by a simulator simulating application software as is well known.
  • FIG. 18 is a block diagram of a functional configuration of the scheduler 1721 according to the second embodiment.
  • the scheduler 1721 includes a reception unit 1801, an exclusion determination unit 1802, a delay time calculation unit 1803, an end time calculation unit 1804, a time determination unit 1805, and an execution control unit 1806.
  • each function (accepting unit 1801 to execution control unit 1806) implements each function by loading the scheduler 1721 stored in the shared memory 1704 and causing the CPU 1701 to execute it, for example.
  • the accepting unit 1801 accepts a target thread generation instruction. Then, upon receiving an instruction to generate a target thread, the exclusion determination unit 1802 determines whether the target thread is a thread that requires exclusive control.
  • the delay time calculation unit 1803 sets a delay possible time that does not require exclusive control at the first reception time when the generation instruction is received.
  • the delay possible time is calculated by adding.
  • the execution end time of the target thread is increased by adding the execution time of the target thread to the second reception time at which the execution start instruction is received. Calculate the time.
  • the time determination unit 1805 determines whether or not the scheduled execution end time calculated by the end time calculation unit 1804 is after the delay possible time calculated by the delay time calculation unit 1803.
  • the execution control unit 1806 locks the data of the generation thread having a dependency relationship with the target thread and then sets the target thread to the multi-core processor. Run on any of the cores. On the other hand, if the time determination unit 1805 determines that the scheduled execution end time is not after the delay possible time, the execution control unit 1806 causes the target thread to be executed by the arbitrary core.
  • FIG. 19 is an explanatory diagram showing a first example of thread A allocation by the scheduler 1721.
  • the thread B is assigned to the CPU 1701 and the thread C is assigned to the CPU 1702. Specifically, for example, when the thread B generates the thread A and notifies the scheduler 1721 of the generation instruction of the thread A, the scheduler 1721 receives the generation instruction of the thread A.
  • the scheduler 1721 determines that the thread A is assigned to the CPU 1702, and registers it in the ready queue of the CPU 1702.
  • the registration of the thread A in the ready queue specifically means that the address of the storage area in which the thread A is loaded is generated as a context and the context is put in the ready queue. Threads are executed in the order of contexts loaded in the ready queue. That is, a thread whose context is registered in the ready queue is in an execution waiting state.
  • the scheduler 1721 reads the thread management table 1600 from the shared memory 1704.
  • the thread management table 1600 may be stored in the cache of the CPU 1701 when the OS 1711 is activated.
  • the scheduler 1721 refers to the thread management table 1600 to determine whether the thread A is a thread that needs exclusive control.
  • Thread A is a thread that requires exclusive control and has a delay time of 99 [ ⁇ s].
  • the scheduler 1721 calculates the delay possible time by adding the delay possible time to the first reception time when the thread A generation instruction is received.
  • the delay possible time may be stored in the cache of the CPU 1701.
  • the scheduler 1721 receives an instruction to start execution of the thread A.
  • Accepting an execution start instruction for thread A detects, for example, that the thread A changes from an execution waiting state to an execution state by monitoring a task switch.
  • the scheduler 1721 accesses the execution time table 1731 and acquires the execution time of the thread A.
  • the execution time of the thread A is 70 [ ⁇ s].
  • the scheduled execution end time of the thread A is calculated by adding the execution time of the thread A to the second reception time when the execution start instruction is received.
  • the scheduler 1721 determines whether or not the scheduled execution end time is after the delay possible time. As shown in FIG. 19, it is determined here that the scheduled execution end time is after the delay possible time.
  • FIG. 20 is an explanatory diagram showing an example in which the thread B performs the spin loop process.
  • the scheduler 1721 locks the data having a dependency relationship between the thread A and the thread B, and causes the CPU 1702 to execute the thread A.
  • the data is locked for the access from the thread B, but the data is not locked for the access from the thread A.
  • the thread B confirms the unlocking of the data by performing a spin loop process.
  • FIG. 21 is an explanatory diagram of a second example of thread A allocation by the scheduler 1721.
  • the thread B is assigned to the CPU 1701 and the thread C is assigned to the CPU 1702. Specifically, for example, when the thread B generates the thread A and notifies the scheduler 1721 of the generation instruction of the thread A, the scheduler 1721 receives the generation instruction of the thread A.
  • the scheduler 1721 determines that the thread A is assigned to the CPU 1702, and registers it in the ready queue of the CPU 1702.
  • the registration of the thread A in the ready queue specifically means that the address of the storage area in which the thread A is loaded is generated as a context and the context is put in the ready queue. Threads are executed in the order of contexts loaded in the ready queue. That is, a thread whose context is registered in the ready queue is in an execution waiting state.
  • the scheduler 1721 reads the thread management table 1600 from the shared memory 1704.
  • the scheduler 1721 refers to the thread management table 1600 to determine whether the thread A is a thread that needs exclusive control.
  • Thread A is a thread that requires exclusive control and has a delay time of 99 [ ⁇ s].
  • An example of calculating the delay time is the same as the processing shown in FIG.
  • the scheduler 1721 receives an instruction to start execution of the thread A.
  • Accepting an execution start instruction for thread A detects, for example, that the thread A changes from an execution waiting state to an execution state by monitoring a task switch.
  • the scheduler 1721 accesses the execution time table 1731 and acquires the execution time of the thread A.
  • the execution time of the thread A is 70 [ ⁇ s].
  • the scheduler 1721 calculates the scheduled execution end time of the thread A by adding the execution time of the thread A to the second reception time when the execution start instruction is received.
  • the scheduler 1721 determines whether or not the scheduled execution end time is after the delay possible time. As shown in FIG. 21, it is determined here that the scheduled execution end time is not after the delay possible time. When the scheduler 1721 determines that the scheduled execution end time is not after the delay possible time, the thread A is executed without locking the data having a dependency relationship between the thread A and the thread B.
  • FIG. 22 is a flowchart showing a control processing procedure by the scheduler 1721.
  • the scheduler 1721 determines whether or not the reception unit 1801 has received a target thread generation instruction (step S2201), and determines that the target thread generation instruction has not been received (step S2201: No). The process returns to S2201.
  • the scheduler 1721 determines that the target thread generation instruction has been received (step S2201: Yes)
  • the CPU to which the thread for which the thread generation instruction has been received is assigned is determined (step S2202).
  • the scheduler 1721 registers the target thread in the ready queue of the determined CPU (step S2203), and the exclusion determination unit 1802 refers to the thread management table 1600 to determine whether the thread requires exclusive control. Is determined (step S2204).
  • the reception unit 1801 determines whether an execution start instruction has been received (step S2205). If the scheduler 1721 determines that an execution start instruction has not been received (step S2205: NO), the process returns to step S2205. On the other hand, when the scheduler 1721 determines that an execution start instruction has been received (step S2205: YES), the process proceeds to step S2211.
  • the scheduler 1721 determines whether or not the reception unit 1801 has received an execution start instruction for the target thread (step S2207), and determines that the execution start instruction for the target thread has not been received (step S2207: No). ), The process returns to step S2207.
  • the scheduler 1721 determines whether or not the scheduled execution end time is after the deferrable time by the time determination unit 1805 (step S2209), and determines that the scheduled execution end time is not after the deferrable time (step S2209). Step S2209: No), the process proceeds to step S2211. On the other hand, when the scheduler 1721 determines that the scheduled execution end time is after the delay possible time (step S2209: Yes), the data that is dependent on the target thread and the parent thread of the target thread is locked (step S2210). . As for the lock to the data, the access from the parent thread is locked, and the access from the target thread is not locked.
  • step S2205 Yes
  • step S2209 No
  • step S2210 execution of the target thread is started (step S2211), and the process returns to step S2201.
  • the first execution result of the generation thread when the target thread is executed in the single-core / multi-thread environment is delayed. It is determined whether or not the second execution result of the generation source thread when the target thread is executed matches. If the first execution result and the second execution result do not match, it is output that exclusive control is required for data having a dependency relationship between the target thread and the generation thread. This allows the designer to prepare semaphores only for the identified threads by automatically identifying the threads that need exclusive control, so the semaphores can be appropriately prepared for the verification target software, and the software design Can be made easier.
  • the delay time for delaying the target thread is increased, and the target thread is executed after being delayed by the increased delay time. Then, the increase in the delay time is repeated until the execution start time of the target thread is after the execution end time of the generation thread, and it is determined whether the first execution result and the second execution result match. Increase the delay time.
  • the delay time for delaying the target thread is reduced. Then, the target thread is executed after being delayed by the reduced delay time. As a result, it is possible to estimate the delay possible time during which the correct value can be guaranteed without using exclusive control.
  • the correct value can be guaranteed without using exclusive control for data having a dependency relationship between threads based on the delay possible time. Dynamically determine whether to lock data. Thus, whether or not to perform exclusive control is determined according to the execution state of the multi-core processor, and it is possible to prevent CPU performance deterioration due to spin loop processing in unnecessary exclusive control.
  • the verification support method described in the first embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation.
  • the verification support program is recorded on a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD, and is executed by being read from the recording medium by the computer.
  • the verification support program may be distributed through a network such as the Internet.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

 一のCPUモデルに割り当てられているスレッド(101)がスレッド(102)を生成し、検証支援装置が、該スレッドの生成を検出し、スレッド(102)を他のCPUモデルに割り当てる。検証支援装置が、スレッド(102)をDELAY分遅延させてから実行させる。検証支援装置が、シングルコア・マルチスレッド環境においてスレッド(102)を実行させた場合のスレッド(101)の第1の実行結果と、遅延させてスレッド(102)を実行させた場合のスレッド(101)の第2の実行結果とが一致するか否かを判断する。検証支援装置は、第1の実行結果と第2の実行結果とが不一致であると判断し、スレッド(101)とスレッド(102)で依存関係のあるデータに排他制御が必要であることを出力する。

Description

検証支援プログラム、制御プログラム、検証支援装置、マルチコアプロセッサシステム、検証支援方法、および制御方法
 本発明は、回路情報をシミュレーションする検証支援プログラム、検証支援装置、および検証支援方法に関する。さらに、スレッドの割り当てを制御する制御プログラム、マルチコアプロセッサシステム、および制御方法に関する。
 従来、マルチスレッド処理を行う場合、スレッド間で依存関係のある共有データへのアクセス競合に対して共有データの一貫性を維持するために、排他制御が行われていた。排他制御の主な手法としてセマフォが挙げられる。マルチコアプロセッサを例に挙げると、セマフォでは、共有データへのアクセスに関して、先にアクセスしたスレッドを動かす一のCPU(Central Processing Unit)が該共有データにロックをかける。そして、該スレッドと異なるスレッドを動作する他のCPUは一のCPUがロックを解除するまで共有データへのアクセスは待ちとなる。
 他のCPUは一定時間ごとにロックを示すロック変数の値を確認すること(スピンループ処理)によりロックの解除が行われたか否かを判断していた。これにより、CPU間で共有データの一貫性を保つことができる。なお、共有データに対してセマフォによるロックをかけるか否かについては検証対象ソフトウェアを参照することで判断することができる(たとえば、下記特許文献1を参照。)。
 また、スレッド間でデータに依存関係があるか否かについては、コンパイラを用いて各変数の生存範囲解析を行うことで検出することができる(たとえば、下記特許文献2を参照。)。
特開2002-132743号公報 特開2003-5981号公報
 しかしながら、シングルコアプロセッサシステムを用いて正常に動作していたマルチスレッドを、マルチコアプロセッサシステムを用いて動作させると、正常に動作しない場合があった。シングルコアプロセッサシステムを用いた場合にデータに依存関係のある2つのスレッドであっても、実行結果が正常であればセマフォのような排他制御を行っていなかった。
 マルチコアプロセッサシステムでは、各CPUに複数のスレッドが割り当てられており、データ依存関係のある2つのスレッドが異なるCPUに割り当てられると、該2つのスレッドの実行のタイミングがずれるという問題点があった。そのため、マルチコアプロセッサシステムを用いた場合の実行結果とシングルコアプロセッサシステムを用いた場合の実行結果とが異なるという問題点があった。
 利用者がスレッド間で依存関係のあるすべての共有データに対して排他制御を行うように検証対象プログラムをコーディングすることで、実行結果が異なるとういう問題点を解決することができる。しかしながら、スピンループ処理が行われると、ロック変数の確認のためだけにCPU資源を浪費してしまうため、セマフォをかける数が多いほど性能が劣化するという問題点があった。さらに、利用者がスレッド間で依存関係のある共有データに対して排他制御を行うか否かを判断するが、依存関係の有無の判断は非常に難しく、プログラムを安全に実行するために、本来必要ではない箇所に対しても排他制御をかけてしまい、CPUのスループットが下がるという問題点があった。
 本発明は、上述した従来技術による問題点を解消するため、排他制御が必要なスレッドを自動で特定することにより、必要最低眼のスレッドに対してのみセマフォを用意することができ、スピンループ処理によるCPUの性能劣化を防止することができる検証支援プログラム、検証支援装置、および検証支援方法を提供することを目的とする。
 上述した課題を解決し、目的を達成するため、開示の検証支援プログラム、検証支援装置、および検証支援方法は、第1のコアモデルと第2のコアモデルを備えるマルチコアプロセッサモデルを用いて検証対象ソフトウェアを模擬し、該検証対象ソフトウェアの模擬中に前記第1のコアモデルに割り当てられた生成元スレッドから対象スレッドの生成命令を検出し、前記対象スレッドの生成命令が検出された場合、前記第2のコアモデルに前記対象スレッドを割り当て、前記第2のコアモデルへ前記対象スレッドが割り当てられると、前記対象スレッドを所定遅延時間遅延させてから実行し、前記第1のコアモデル上で、マルチスレッド環境において前記対象スレッドを実行させた場合の前記生成元スレッドの第1の実行結果と、遅延させて前記対象スレッドを実行させた場合の前記生成元スレッドの第2の実行結果とが一致するか否かを判断し、前記第1の実行結果と前記第2の実行結果とが不一致であると判断された場合、前記対象スレッドに排他制御が必要な旨の情報を出力することを要件とする。
 本検証支援プログラム、検証支援装置、および検証支援方法によれば排他制御が必要なスレッドを自動で特定することにより、必要最低眼のスレッドに対してのみセマフォを用意することができ、スピンループ処理によるCPUの性能劣化を防止することができるという効果を奏する。
本発明の一実施例を示す説明図である。 マルチコアプロセッサシステムモデルに関する回路情報を示す説明図である。 検証対象ソフトウェアの一例を示す説明図である。 検証対象ソフトウェア300における変数の生存区間を示す説明図である。 データ依存テーブルの一例を示す説明図である。 実施の形態1にかかる検証支援装置のハードウェア構成を示すブロック図である。 検証支援装置600の機能的構成を示すブロック図である。 マルチコアプロセッサシステムを用いて検証対象ソフトウェア300がシミュレーションされている例を示す説明図である。 対象スレッド802が遅延されてから実行される例を示す説明図である。 対象スレッド802を遅延する遅延時間が増える例1を示す説明図である。 対象スレッド802を遅延する遅延時間が増える例2を示す説明図である。 検証支援装置600による検証処理手順の一例を示すフローチャートである。 図12で示した特定処理(ステップS1207)の詳細な説明を示すフローチャートである。 図12および図13で示したスレッド管理テーブル1400の一例を示す説明図である。 図12で示した特定処理(ステップS1208)の詳細な説明を示すフローチャートである。 図12および図15で示したスレッド管理テーブル1600の一例を示す説明図である。 実施の形態2にかかるマルチコアプロセッサシステムのハードウェア構成を示す説明図である。 実施の形態2にかかるスケジューラ1721の機能的構成を示すブロック図である。 スケジューラ1721によるスレッドAの割り当て例1を示す説明図である。 スレッドBがスピンループ処理を行う例を示す説明図である。 スケジューラ1721によるスレッドAの割り当て例2を示す説明図である。 スケジューラ1721による制御処理手順を示すフローチャートである。
 以下に添付図面を参照して、本発明にかかる検証支援プログラム、検証支援装置、および検証支援方法の好適な実施の形態を詳細に説明する。なお、スレッドとは周知のようにアプリケーション内で行われる処理の実行単位である。
 図1は、本発明の一実施例を示す説明図である。まず、マルチコアプロセッサシステムモデルを用いて検証対象ソフトウェアをシミュレーションし、スレッド101から生成されたスレッド102が同一のプロセッサモデル上でマルチスレッド処理において実行された場合を例に挙げて説明する。変数a~eまでの初期値は下記とする。
 初期値:a=0,b=1,c=2,d=3,e=0
 スレッド101は一のCPUモデルに割り当てられている。まず、検証支援装置はa=bとc=dを計算する。ここで、aは1となり、cは3となる。
 そして、スレッド101が「a=c」の計算をスレッド102として生成する。そして、生成したスレッド102が「a=c」を計算し、aは3となる。つぎに、「b=b+d」により、bは4となり、「c=d」によりcは3となり、「e=a-c」によりeは0となり、「d=c」によりdは3となる。すなわち、シングルコア・マルチスレッド環境においてスレッド102を実行させた場合のスレッド101の第1の実行結果を下記に示す。
 ・第1の実行結果:a=3,b=4,c=3,d=3,e=0
 検証支援装置は、実行結果をアクセス可能な記憶装置に記憶して、該第1の実行結果を、遅延させてスレッド102を実行させた場合のスレッド101の第2の実行結果と比較するために用いる。
 つぎに、スレッド101から生成されたスレッド102が負荷を与えられて実行された場合を例に挙げて説明する。まず、検証支援装置は「a=b」と「c=d」とを計算する。aは1となり、cは3となる。つぎに、「a=c」の計算があらたにスレッド102として生成されると、検証支援装置が、該スレッド102の生成を検出し、マルチコアプロセッサのうち、該親スレッドが割り当てられている一のCPUモデルと異なる他のCPUモデルに生成されたスレッドを割り当てる。
 ここで、検証支援装置が、スレッド102に負荷を与えている。ここで、スレッド102に負荷を与えるとは、スレッド102をDELAY分遅延させてから実行させることである。よって、図1では、「c=d」のつぎに「b=b+d」が計算され、「e=a―c」が計算され、「d=c」が計算されてから「a=c」が計算される。すなわち、遅延させてスレッド102を実行させた場合のスレッド101の第2の実行結果を下記に示す。
 ・第2の実行結果:a=3,b=4,c=3,d=3,e=-3
 そして、検証支援装置が、記憶装置に記憶されている第1の実行結果と第2の実行結果とが一致しているか否かを判断する。ここで、第1の実行結果と第2の実行結果とは変数eの値が異なるため、不一致であると判断される。不一致であると判断されると、検証支援装置は、スレッド101が排他制御を必要とするスレッドであることを出力する。なお、排他制御を必要とするスレッドとは、スレッド間で依存関係のあるデータに対して、排他制御が必要であることを意味する。図1では、スレッド間で依存関係のあるデータは変数aである。
 まず、実施の形態1では、スレッド間で依存関係のあるデータに排他制御の必要があるか否かを自動で特定する例と、排他制御が必要な場合であっても排他制御を必要としない遅延可能時間を特定する例とについて説明する。そして、実施の形態2では、マルチコアプロセッサシステムにおいてスケジューラが実施の形態1で特定された遅延可能時間を用いてスレッドの割り当て時に共有データに対してロックをかけるか否かを判断する例について説明する。
(実施の形態1)
(マルチコアプロセッサシステムモデルに関する回路情報)
 図2は、マルチコアプロセッサシステムモデルに関する回路情報を示す説明図である。回路情報200は、ESL(Electronic System Level)用のモデルである。そして、回路情報200は、マルチコアプロセッサモデルを備えるマルチコアプロセッサシステムモデルの各CPUモデルや該各CPUモデルの接続関係などがSystemCおよびXML(Extensible Markup Language)スクリプトによるハードウェア記述で表されている。
 ここで、ESL技術とは、システムLSIの設計を、段階ごとに詳細性(抽象性)を変えながら行うシステム上流工程設計での高速シミュレーション技術である。ESL技術では、詳細なクロック動作などを適宜スキップ、隠蔽することで高速動作を行うことができる。ESL技術は、CPUのインストラクションシミュレータと連動させることで、ソフトウェア動作可能なシミュレーション環境として利用されている。ESL技術は、SoC(System on a Chip)などの大規模システムLSI(Large Scale Integrated)開発に用いられる。
 回路情報200では、第1のCPUモデル201と第2のCPUモデル202と共有メモリモデル204が備えられている。各構成部はバスモデル203を介して接続されている。第1のCPUモデル201と第2のCPUモデル202とはそれぞれキャッシュやレジスタを備えている。検証支援装置がシミュレーションを実行すると、第1のCPUモデル201はマスタOS211を起動し、第2のCPUモデル202はスレーブOS212を起動する。
(検証対象ソフトウェア)
 図3は、検証対象ソフトウェアの一例を示す説明図である。検証対象ソフトウェア300では、プログラムの一例を示している。検証支援装置が、マルチコアプロセッサシステムを用いて検証対象ソフトウェア300をシミュレーションすることで、検証対象ソフトウェア300内にコーディングされている処理(スレッド)が第1のCPUモデル201(または第2のCPUモデル202)に割り当てられる。
 検証対象ソフトウェア300には、「a=b」と「a=c」と「c=d」と「e=a-c」との計算式と、スレッドの生成命令である「pthread_create();」と、スレッドの結合命令である「pthread_join();」とがコーディングされている。検証対象ソフトウェア300にコーディングされている処理を生成元スレッドと称する。
 また、検証支援装置が、生成元スレッドから対象スレッドの生成命令を検出するとは、たとえば、「pthread_create();」を検出することである。ここで、生成元スレッドから「pthread_create();」により生成されるスレッドを対象スレッドと呼ぶ。
 また、生成元スレッドと対象スレッド間で依存関係があるか否かについては、コンパイラにより検出することができる。つぎに、変数の生存区間について説明する。
 図4は、検証対象ソフトウェア300における変数の生存区間を示す説明図である。変数の生存区間とは、ある変数が検証対象ソフトウェア300においてどこからどこまでの間で変化するかを示す。検証対象ソフトウェア300の先頭で変数aは「a=b」の計算が行われ、その後、「a=c」が行われている。よって、「a=b」から「a=c」までが変数aの生存区間である。変数の生存区間は、検証対象ソフトウェア300をコンパイラの解析部により検出することができる。
 変数aのように変数の生存区間がスレッドの生成命令をまたがっている場合、生成元スレッドと対象スレッドには依存関係がある。すなわち、変数の生存区間をコンパイラにより解析することで、生成元スレッドと対象スレッドとに依存関係があるか否かが判別される。さらに、コンパイラによりセマフォがあるか否かを解析することにより、各スレッドにセマフォがあるか否かが判別される。
(データ依存テーブル)
 図5は、データ依存テーブルの一例を示す説明図である。データ依存テーブル500では、親スレッドと該親スレッドにより生成される子スレッドとにデータの依存関係があるか否かと、親スレッドと子スレッドとにセマフォがあるか否かを示すテーブルである。データ依存テーブル500は、子スレッドごとに用意されていることとする。なお、データ依存テーブル500は、コンピュータがアクセス可能な記憶装置に記憶されている。
(実施の形態1にかかる検証支援装置のハードウェア構成)
 図6は、実施の形態1にかかる検証支援装置のハードウェア構成を示すブロック図である。図6において、検証支援装置600は、CPU(Central Processing Unit)601と、ROM(Read‐Only Memory)602と、RAM(Random Access Memory)603と、磁気ディスクドライブ604と、磁気ディスク605と、光ディスクドライブ606と、光ディスク607と、ディスプレイ608と、I/F(Interface)609と、キーボード610と、マウス611と、スキャナ612と、プリンタ613と、を備えている。また、各構成部はバス615によってそれぞれ接続されている。
 ここで、CPU601は、検証支援装置600の全体の制御を司る。ROM602は、ブートプログラムなどのプログラムを記憶している。RAM603は、CPU601のワークエリアとして使用される。磁気ディスクドライブ604は、CPU601の制御にしたがって磁気ディスク605に対するデータのリード/ライトを制御する。磁気ディスク605は、磁気ディスクドライブ604の制御で書き込まれたデータを記憶する。
 光ディスクドライブ606は、CPU601の制御にしたがって光ディスク607に対するデータのリード/ライトを制御する。光ディスク607は、光ディスクドライブ606の制御で書き込まれたデータを記憶したり、光ディスク607に記憶されたデータをコンピュータに読み取らせたりする。
 ディスプレイ608は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ608は、たとえば、CRT、TFT液晶ディスプレイ、プラズマディスプレイなどを採用することができる。
 インターフェース(以下、「I/F」と略する。)609は、通信回線を通じてLAN(Local Area Network)、WAN(Wide Area Network)、インターネットなどのネットワーク614に接続され、このネットワーク614を介して他の装置に接続される。そして、I/F609は、ネットワーク614と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。I/F609には、たとえばモデムやLANアダプタなどを採用することができる。
 キーボード610は、文字、数字、各種指示などの入力のためのキーを備え、データの入力を行う。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス611は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などを行う。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。
 スキャナ612は、画像を光学的に読み取り、検証支援装置600内に画像データを取り込む。なお、スキャナ612は、OCR(Optical Character Reader)機能を持たせてもよい。また、プリンタ613は、画像データや文書データを印刷する。プリンタ613には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。
(検証支援装置600の機能的構成)
 図7は、検証支援装置600の機能的構成を示すブロック図である。検証支援装置600は、検出部701と、割り当て部702と、保持部703と、実行制御部704と、一致判断部705と、時刻判断部706と、設定部707と、調整部708と、出力部709と、を含む構成である。各機能(検出部701~出力部709)は、具体的には、たとえば、図6に示したROM602、RAM603、磁気ディスク605、光ディスク607などの記憶装置に記憶されたプログラムをCPU601に実行させることにより、または、I/F609により、各機能を実現する。
 まず、検出部701は、回路情報200を用いて検証対象ソフトウェア300のシミュレーション中に第1のCPUモデル201に割り当てられた生成元スレッドから対象スレッドの生成命令を検出する。
 割り当て部702は、検出部701により対象スレッドの生成命令が検出された場合、第2のCPUモデル202に対象スレッドを割り当てる。なお、生成元スレッドが第1のCPUモデル201に割り当てられているとし、対象スレッドを第2のCPUモデル202に割り当てることとしているが、対象スレッドと生成元スレッドが異なるCPUモデルに割り当てられればよい。
 実行制御部704は、割り当て部702により第2のCPUモデル202へ対象スレッドが割り当てられると、対象スレッドを所定遅延時間遅延させてから実行する。
 一致判断部705は、シングルコア・マルチスレッド環境において対象スレッドを実行させた場合の生成元スレッドの第1の実行結果と、実行制御部704により遅延させて対象スレッドを実行させた場合の生成元スレッドの第2の実行結果とが一致するか否かを判断する。なお、シングルコア・マルチスレッド環境において対象スレッドを実行させた場合の生成元スレッドの第1の実行結果とは、マルチコアプロセッサシステムのモデルにおいて遅延させずに対象スレッドを実行させた場合の生成元スレッドの第1の実行結果と同一である。よって、第1の実行結果とは、遅延させずに対象スレッドを実行させた場合の生成元スレッドの実行結果である。
 出力部709は、第1の実行結果と第2の実行結果とが不一致であると判断された場合、対象スレッドに排他制御が必要な旨の情報を出力する。
 また、保持部703は、検出部701により対象スレッドの生成命令が検出されると、対象スレッドの生成命令の一命令前における生成元スレッドの実行状態を保持する。
 そして、時刻判断部706は、一致判断部705により第1の実行結果と第2の実行結果とが一致すると判断された場合、遅延させた場合の対象スレッドの実行開始時刻が生成元スレッドの実行終了時刻以降であるか否かを判断する。
 設定部707は、時刻判断部706により対象スレッドの実行開始時刻が生成元スレッドの実行終了時刻以降でないと判断された場合、保持部703により保持された生成元スレッドの実行状態に設定する。
 調整部708は、所定遅延時間を所定時間長くする。そして、実行制御部704は、設定部707による設定後の生成元スレッドを実行し、対象スレッドを調整部708により長くされた所定遅延時間遅延させてから実行する。一致判断部705は、第1の実行結果と第2の実行結果とが一致するか否かを判断する。
 また、出力部709は、時刻判断部706により対象スレッドの実行開始時刻が生成元スレッドの実行終了時刻以降であると判断された場合、対象スレッドに排他制御が必要でない旨の情報を出力する。
 また、設定部707は、一致判断部705により第1の実行結果と第2の実行結果とが不一致であると判断された場合、生成元スレッドの実行状態を保持された生成元スレッドの実行状態に設定する。
 調整部708は、所定遅延時間を所定時間短くする。つぎに、実行制御部704は、設定部707による設定後の生成元スレッドを実行し、対象スレッドを調整部708により短くした所定遅延時間遅延させてから実行する。
 そして、一致判断部705は、短くした所定遅延時間遅延させて対象スレッドを実行制御部704により実行させた場合の生成元スレッドの第2の実行結果と、第1の実行結果とが一致するか否かを判断する。
 出力部709は、一致判断部705により第1の実行結果と第2の実行結果とが一致すると判断された場合、短くした所定遅延時間を遅延可能時間とし、対象スレッドに排他制御が必要な旨の情報に遅延可能時間を関連付けて出力する。
 以上を踏まえて図を用いて詳細に説明する。
 図8は、マルチコアプロセッサシステムを用いて検証対象ソフトウェア300がシミュレーションされている例を示す説明図である。図8では、検証対象ソフトウェア300にコーディングされている生成元スレッド801が第1のCPUモデル201に割り当てられて実行されて。具体的には、たとえば、CPU601が、(1)検証対象ソフトウェア300内にコーディングされている生成元スレッド801から対象スレッド802の生成命令を検出する。
 そして、具体的には、たとえば、CPU601が、対象スレッド802の生成命令を検出すると、データ依存テーブル500に基づいて対象スレッド802と生成元スレッド801とに依存関係があるか否かを判断する。対象スレッド802と生成元スレッド801とに依存関係があると判断された場合、CPU601が、対象スレッド802にセマフォがあるか否かをデータ依存テーブル500に基づいて判断する。対象スレッド802にセマフォがないと判断された場合、CPU601が、(2)対象スレッド802を第2のCPUモデル202に割り当てる。そして、具体的には、たとえば、CPU601が、対象スレッド802の生成命令の一つ前の命令の生成元スレッド801の実行状態を保存する。ここで、実行状態とは、具体的には、たとえば、各変数の値と、検証対象ソフトウェア300上での実行位置である。
 図9は、対象スレッド802が遅延されてから実行される例を示す説明図である。あらかじめ遅延させる所定遅延時間を定義し、CPU601が、該所定遅延時間分対象スレッド802の実行を遅延させる。本実施の形態では、所定遅延時間をDELAYとし、所定時間をDELとしている。ここでは、たとえば、DEL=1[μs]とする。まず、DELAY=DELとし、対象スレッド802が第2のCPUモデル202に割り当てられ、DELAY分遅延されて実行されている。
 そして、たとえば、CPU601が、生成元スレッド801および対象スレッド802の実行が終了すると、記憶装置から、シングルコア・マルチスレッド環境において対象スレッド802が実行された場合の生成元スレッド801の第1の実行結果を取得する。なお、ここでは、遅延されずに対象スレッド802が実行された場合の生成元スレッド801の第1の実行結果は、図1で示した第1の実行結果と同一であり、RAM603、磁気ディスク605、光ディスク607などの記憶装置に記憶されていることとする。つぎに、CPU601が、遅延されて対象スレッド802が実行された第2の実行結果と取得した第1の実行結果が一致するか否かを判断する。ここで、第1の実行結果と第2の実行結果とを下記に示す。ここでは、第1の実行結果と第2の実行結果とは一致すると判断される。
 ・第1の実行結果:a=3,b=4,c=3,d=3,e=0
 ・第2の実行結果:a=3,b=4,c=3,d=3,e=0
 そして、第1の実行結果と第2の実行結果が一致すると判断された場合、具体的には、たとえば、CPU601が、対象スレッド802の実行開始時刻が生成元スレッド801の実行終了時刻以降であるか否かを判断する。なお、たとえば、CPU601は、各スレッドの実行開始時刻や実行終了時刻についてはあらかじめ実行時および実行終了時にRAM603、磁気ディスク605、光ディスク607などの記憶装置に記憶することとする。ここでは、CPU601が、対象スレッド802の実行開始時刻が生成元スレッド801の実行終了時刻以降でないと判断する。
 図10は、対象スレッド802を遅延する遅延時間が増える例1を示す説明図である。対象スレッド802の実行開始が生成元スレッド801の実行終了よりも早いと判断されると、CPU601が、DELAY=DELAY+DELとし、生成元スレッド801の実行状態を保存した実行状態に設定する。
 生成元スレッド801の実行状態を保存した実行状態に設定するとは、CPU601が、たとえば、第1のCPUモデル201の命令位置を保存された実行状態の実行位置にジャンプさせる。そして、CPU601が、第1のCPUモデル201のキャッシュに記憶されている各変数を該保存された実行状態の各変数に変更することである。
 つぎに、具体的には、たとえば、CPU601が、生成元スレッド801を実行し、対象スレッド802をDELAY分遅延させてから実行する。そして、たとえば、CPU601が、生成元スレッド801および対象スレッド802の実行が終了すると、記憶装置から第1の実行結果を取得する。以下に第1の実行結果と第2の実行結果を示す。
 ・第1の実行結果:a=3,b=4,c=3,d=3,e=0
 ・第2の実行結果:a=3,b=4,c=3,d=3,e=0
 ここでは、第1の実行結果と第2の実行結果が一致すると判断される。そして、第1の実行結果と第2の実行結果が一致すると判断された場合、具体的には、たとえば、CPU601が、対象スレッド802の実行開始が生成元スレッド801の実行終了よりも早いか否かを判断する。
 第1の実行結果と第2の実行結果が一致すると判断された場合には、対象スレッド802の実行開始時刻が生成元スレッド801の実行終了時刻以降であると判断されるまで、CPU601がDELAYを増加し、遅延させて対象スレッド802を実行する処理を繰り返す。
 図11は、対象スレッド802を遅延する遅延時間が増える例2を示す説明図である。具体的には、たとえば、CPU601が、DELAY=DELAY+DELとし、生成元スレッド801の実行状態を保存した対象スレッド802の生成命令直前までの生成元スレッド801の実行状態に戻す。
 つぎに、具体的には、たとえば、CPU601が、生成元スレッド801を実行し、対象スレッド802をDELAY分遅延させてから実行する。以下に第1の実行結果と第2の実行結果を示す。
 ・第1の実行結果:a=3,b=4,c=3,d=3,e=0
 ・第2の実行結果:a=3,b=4,c=3,d=3,e=-3
 ここでは、第1の実行結果と第2の実行結果が一致しないと判断され、具体的には、たとえば、CPU601が、対象スレッド802にセマフォが必要であることを出力する。たとえば、対象スレッド802と検証対象ソフトウェア300で対象スレッド802の行番号等を併せて出力してもよい。出力形式としては、たとえば、ディスプレイ608への表示、プリンタ613への印刷出力、I/F609による外部装置への送信がある。また、RAM603、磁気ディスク605、光ディスク607などの記憶装置に記憶することとしてもよい。
(検証支援装置600による検証処理手順)
 図12は、検証支援装置600による検証処理手順の一例を示すフローチャートである。まず、検証支援装置600が、検証対象ソフトウェアを実行し(ステップS1201)、検出部701により、実行中のスレッド(生成元スレッド)から対象スレッドの生成命令を検出したか否かを判断する(ステップS1202)。検証支援装置600が、対象スレッドの生成命令を検出していないと判断した場合(ステップS1202:No)、ステップS1202へ戻る。一方、検証支援装置600が、対象スレッドの生成命令を検出したと判断した場合(ステップS1202:Yes)、対象スレッドがセーフスレッドに登録されているか、またはセマフォの必要ありと判断されたか否かを判断する(ステップS1203)。セーフスレッドとは、セマフォの必要がないスレッドを示している。
 検証支援装置600が、対象スレッドがセーフスレッドに登録されている、またはセマフォの必要ありと判断されていると判断した場合(ステップS1203:Yes)、任意のCPUモデルに割り当て、対象スレッドを実行し(ステップS1204)、検証対象ソフトウェアが終了したか否かを判断する(ステップS1205)。検証支援装置600が検証対象ソフトウェアが終了していないと判断した場合(ステップS1205:No)、ステップS1202へ戻る。
 一方、検証支援装置600が、対象スレッドがセーフスレッドに登録されていない、かつセマフォの必要ありと判断されていないと判断した場合(ステップS1203:No)、対象スレッドと生成元スレッドとに依存関係があり、かつセマフォがないかを判断する(ステップS1206)。
 検証支援装置600が、対象スレッドと生成元スレッドとに依存関係がない、またはセマフォがあると判断した場合(ステップS1206:No)、ステップS1204へ移行する。一方、検証支援装置600が、対象スレッドと生成元スレッドとに依存関係があり、かつセマフォがないと判断した場合(ステップS1206:Yes)、特定処理を実行し(ステップS1207(またはステップS1208))、ステップS1201へ戻る。
 一方、ステップS1205において、検証支援装置600が、検証対象ソフトウェアが終了したと判断した場合(ステップS1205:Yes)、一連の処理を終了する。
 図13は、図12で示した特定処理(ステップS1207)の詳細な説明を示すフローチャートである。まず、検証支援装置600が、保持部703により、対象スレッドの生成命令の一つ前の命令の生成元スレッドの実行状態を保存する(ステップS1301)。そして、検証支援装置600が、割り当て部702により、対象スレッドを生成元スレッドと異なるCPUモデルに割り当てる(ステップS1302)。
 そして、検証支援装置600が、DELAY=DELとし(ステップS1303)、実行制御部704により、対象スレッドをDELAY分遅延させてから実行する(ステップS1304)。つぎに、検証支援装置600が、一致判断部705により、シングルコア・マルチスレッド環境において対象スレッドを実行させた場合の生成元スレッドの第1の実行結果と遅延させて対象スレッドを実行させた場合の生成元スレッドの第2の実行結果とが一致するか否かを判断する(ステップS1305)。
 まず、第1の実行結果と第2の実行結果とが不一致であると判断された場合(ステップS1305:No)、検証支援装置600が、出力部709により、対象スレッドにセマフォの必要があることを出力し(ステップS1306)、ステップS1201へ戻る。ここでは、検証支援装置600がスレッド管理テーブル1400に出力している。スレッド管理テーブルの例は後述する。一方、第1の実行結果と第2の実行結果とが一致すると判断された場合(ステップS1305:Yes)、検証支援装置600が、時刻判断部706により、対象スレッドの実行開始時刻が生成元スレッドの実行終了時刻以降であるか否かを判断する(ステップS1307)。
 対象スレッドの実行開始時刻が生成元スレッドの実行終了時刻以降であると判断された場合(ステップS1307:Yes)、検証支援装置600が、出力部709により、対象スレッドをスレッド管理テーブル1400内のセーフスレッドに登録し(ステップS1308)、ステップS1201へ戻る。一方、対象スレッドの実行開始時に生成元スレッドの実行が終了していないと判断された場合(ステップS1307:No)、検証支援装置600が、調整部708により、DELAY=DELAY+DELとする(ステップS1309)。検証支援装置600が、設定部707により、対象スレッドの実行状態を保存した実行状態に設定し(ステップS1310)、ステップS1304へ戻る。
 図13では、DELAYを増加させているが、検証支援装置600が、生成元スレッドの実行時間より大きい値をDELAYに設定し、第1の実行結果と第2の実行結果とが一致するか否かを判定し、セマフォの必要があるか否かを判断しても良い。
 図14は、図12および図13で示したスレッド管理テーブル1400の一例を示す説明図である。スレッド管理テーブル1400では、検証対象プログラムで親スレッドと子スレッド間でデータ依存関係があり、かつセマフォがない各スレッドが排他制御の必要がないセーフスレッドか排他制御が必要なスレッドであるかのいずれかに登録されている。スレッド管理テーブル1400では、スレッドCとスレッドDがセーフスレッドとして登録され、スレッドAが排他制御の必要なスレッドとして登録されている。検証対象ソフトウェアの設計者はスレッド管理テーブル1400を参照することにより、排他制御が必要なスレッドが分かり、必要最低限の共有データに対してのみ排他制御を行うように検証対象ソフトウェアに入れることができる。これにより、スピンループ処理を減らすことができ、CPUのスループットを向上させることができる。
 また、図13では対象スレッドに排他制御が必要か否かについて示したが、遅延時間が短ければ排他制御が必要でない場合があるため、排他制御が必要でない遅延時間を遅延可能時間として特定する特定処理手順を図15で示す。
 図15は、図12で示した特定処理(ステップS1208)の詳細な説明を示すフローチャートである。図15のステップS1501~ステップS1505とステップS1508~ステップS1511とは、それぞれ図13のステップS1301~ステップS1305とステップS1307~ステップS1310と同一ステップであるため、詳細な説明を省略する。そして、ステップS1506において、検証支援装置600が、遅延可能時間=DELAY-DELとし(ステップS1506)、対象スレッドを排他制御が必要なスレッドとして遅延可能時間と関連付けて出力する(ステップS1507)。ここでは、検証支援装置600がスレッド管理テーブル1600へ出力する。
 図13では、DELAYを増加させることにより、遅延可能時間を特定しているが、あらかじめDELAYに大きな値を入れて、第1の実行結果と第2の実行結果とが不一致した場合のDELAYから遅延時間を減少させることにより遅延可能時間を特定してもよい。
 たとえば、検証支援装置600が、DELAYの初期値を子スレッドの生成命令の一つ前の命令の実行開始時刻から親スレッドの実行終了時刻までの時間に設定し、子スレッドをDELAY分遅延させて実行させる。そして、検証支援装置600が、第1の実行結果と第2の実行結果が一致するか否かを判断する。一致しない場合には、検証支援装置600が、調整部708によりDELAY=DELAY-DELとして、親スレッドの実行状態を子スレッドの実行開始の一つ前の命令の実行状態に戻す。そして、検証支援装置600が、親スレッドを実行し、子スレッドを、減少させたDELAY分遅延させてから実行する。検証支援装置600は、第1の実行結果と第2の実行結果とが一致するまでDELAYの減少と再実行を繰り返すことで、遅延可能時間を特定することができる。つぎに、図16を用いてスレッド管理テーブル1600について説明する。
 図16は、図12および図15で示したスレッド管理テーブル1600の一例を示す説明図である。スレッド管理テーブル1600では、親スレッドと子スレッド間でデータ依存関係があり、かつセマフォがない各スレッドが排他制御の必要がないセーフスレッドか排他制御が必要なスレッドであるかのいずれかに登録されている。スレッド管理テーブル1600では、スレッドCとスレッドDがセーフスレッドとして登録され、排他制御が必要なスレッドには、スレッド名と、該スレッド名で示すスレッドに依存関係があるスレッドと、遅延可能時間とが登録されている。排他制御が必要なスレッドとしてスレッドAが登録され、スレッドBとデータに依存関係があることと、遅延可能時間が99[μs]であることが示されている。なお、遅延可能時間に0が登録されている場合は遅延させることができないため、セマフォによるロックが必要である。
 マルチコアプロセッサシステムでスケジューラが、スレッド管理テーブル1600を用いることで排他制御が必要なスレッドを特定でき、かつ遅延可能時間を参照することで動的にロックをかけるか否かを決定することができる。
(実施の形態2)
 つぎに、実施の形態2では、マルチコアプロセッサシステムにおいてスケジューラによる実施の形態1で作成されたメモリ管理テーブルを用いてスレッド間で依存関係のあるデータにロックをかけるか否かの制御例について説明する。なお、実施の形態2のマルチコアプロセッサシステムにおいて、マルチコアプロセッサとは、コアが複数搭載されたプロセッサである。コアが複数搭載されていれば、複数のコアが搭載された単一のプロセッサでもよく、シングルコアのプロセッサが並列されているプロセッサ群でもよい。なお、実施の形態2では、説明を単純化するため、シングルコアのプロセッサが並列されているプロセッサ群を例に挙げて説明する。
(実施の形態2にかかるマルチコアプロセッサシステムのハードウェア構成)
 図17は、実施の形態2にかかるマルチコアプロセッサシステムのハードウェア構成を示す説明図である。マルチコアプロセッサシステム1700は、CPU1701およびCPU1702と、共有メモリ1704とを備えている。各構成部はバス1703により接続されている。
 CPU1701とCPU1702とは、それぞれキャッシュとレジスタとコアを備えている。CPU1701上ではマスタOSであるOS1711が動作し、CPU1702上ではスレーブOSであるOS1712が動作する。OS1711はスケジューラ1721を備え、スケジューラ1721が、スレッドの割り当てを決定する。
 共有メモリ1704には、マルチコアプロセッサに共有されるメモリであり、OS1711やOS1712などのブートプログラムとアプリケーションソフトウェアなどのプログラムやスレッド管理テーブル1600や実行時間テーブル1731を記憶している。共有メモリ1704は、具体的には、ROM(Read Only Memory)と、RAM(Random Access Memory)と、フラッシュROMなどを備えている。
 たとえば、ROMが、該プログラムなどを記憶し、RAMは、CPU1701とCPU1702のワークエリアとして使用される。共有メモリ1704に記憶されているプログラムは、各CPUにロードされることで、コーディングされている処理をCPUに実行させることとなる。
 ここで、実行時間テーブル1731とは、各スレッドの実行時間が登録されているテーブルである。各スレッドの実行時間については、周知のようにシミュレータがアプリケーションソフトウェアをシミュレーションすることにより算出することができる。
(実施の形態2にかかるスケジューラ1721の機能的構成)
 図18は、実施の形態2にかかるスケジューラ1721の機能的構成を示すブロック図である。スケジューラ1721は、受付部1801と、排他判断部1802と、遅延時刻算出部1803と、終了時刻算出部1804と、時刻判断部1805と、実行制御部1806と、を含む構成である。各機能(受付部1801~実行制御部1806)は、具体的には、たとえば、共有メモリ1704に記憶されたスケジューラ1721をロードしてCPU1701に実行させることにより、各機能を実現する。
 まず、受付部1801は、対象スレッドの生成指示を受け付ける。そして、排他判断部1802は、対象スレッドの生成指示を受け付けると、対象スレッドが排他制御を必要とするスレッドであるか否かを判断する。
 遅延時刻算出部1803は、排他判断部1802により対象スレッドが排他制御を必要とするスレッドであると判断された場合、生成指示を受け付けた第1の受付時刻に排他制御が不要な遅延可能時間を加算することにより遅延可能時刻を算出する。
 終了時刻算出部1804は、第1の受付時刻経過後、対象スレッドの実行開始指示を受け付けると、実行開始指示を受け付けた第2の受付時刻に対象スレッドの実行時間を加算することにより予定実行終了時刻を算出する。
 時刻判断部1805は、終了時刻算出部1804により算出された予定実行終了時刻が遅延時刻算出部1803により算出された遅延可能時刻以降であるか否かを判断する。
 実行制御部1806は、時刻判断部1805により予定実行終了時刻が遅延可能時刻以降であると判断された場合、対象スレッドに依存関係がある生成元スレッドのデータをロックしてから対象スレッドをマルチコアプロセッサのうちの任意のコアで実行させる。一方、実行制御部1806は、時刻判断部1805により予定実行終了時刻が遅延可能時刻以降でないと判断された場合、対象スレッドを該任意のコアで実行させる。
 以上を踏まえて図を用いて詳細に説明する。
 図19は、スケジューラ1721によるスレッドAの割り当て例1を示す説明図である。図19では、スレッドBがCPU1701に割り当てられ、スレッドCがCPU1702に割り当てられているとする。具体的には、たとえば、スレッドBがスレッドAを生成し、スレッドAの生成指示をスケジューラ1721へ通知すると、スケジューラ1721が、スレッドAの生成指示を受け付ける。
 そして、スケジューラ1721がスレッドAをCPU1702に割り当てると決定し、CPU1702のレディーキューに登録する。なお、スレッドAをレディーキューに登録するとは、具体的には、スレッドAがローディングされた記憶領域のアドレスをコンテキストとして生成し、該コンテキストをレディーキューに入れることである。レディーキューに積まれているコンテキスト順にスレッドが実行される。すなわち、レディーキューにコンテキストが登録されているスレッドは、実行待ち状態である。
 そして、スケジューラ1721が、共有メモリ1704からスレッド管理テーブル1600を読み出す。なお、スレッド管理テーブル1600は、OS1711の起動時にCPU1701のキャッシュに記憶させておいてもよい。スケジューラ1721が、スレッド管理テーブル1600を参照することでスレッドAは排他制御が必要なスレッドであるか否かを判断する。
 スレッドAは排他制御が必要なスレッドであり、遅延可能時間が99[μs]である。スケジューラ1721が、スレッドAの生成指示を受け付けた第1の受付時刻に遅延可能時間を加算することで遅延可能時刻を算出する。なお、遅延可能時刻は該CPU1701のキャッシュに記憶させておいてもよい。
 そして、スケジューラ1721が、スレッドAの実行開始指示を受け付ける。スレッドAの実行開始指示を受け付けるとは、たとえば、タスクスイッチを監視することにより、スレッドAが実行待ち状態から実行状態になることを検出する。
 つぎに、スケジューラ1721が、実行時間テーブル1731にアクセスしてスレッドAの実行時間を取得する。ここで、スレッドAの実行時間を70[μs]とする。スケジューラ1721が、スレッドAの実行開始指示を受け付けると実行開始指示を受け付けた第2の受付時刻にスレッドAの実行時間を加算することによりスレッドAの予定実行終了時刻を算出する。
 そして、スケジューラ1721が、予定実行終了時刻が遅延可能時刻以降であるか否かを判断する。図19で示すように、ここでは、予定実行終了時刻が遅延可能時刻以降であると判断される。
 図20は、スレッドBがスピンループ処理を行う例を示す説明図である。つぎに、予定実行終了時刻が遅延可能時刻以降であると判断され、スケジューラ1721が、スレッドAとスレッドBとで依存関係のあるデータにロックをかけ、スレッドAをCPU1702に実行させる。なお、スレッドBからのアクセスに対して該データはロックがかけられているが、スレッドAからのアクセスに対して該データはロックがかけられていない。そして、スレッドBはスピンループ処理を行うことで該データのロック解除を確認する。
 図21は、スケジューラ1721によるスレッドAの割り当て例2を示す説明図である。図21では、スレッドBがCPU1701に割り当てられ、スレッドCがCPU1702に割り当てられているとする。具体的には、たとえば、スレッドBがスレッドAを生成し、スレッドAの生成指示をスケジューラ1721へ通知すると、スケジューラ1721が、スレッドAの生成指示を受け付ける。
 そして、スケジューラ1721がスレッドAをCPU1702に割り当てると決定し、CPU1702のレディーキューに登録する。なお、スレッドAをレディーキューに登録するとは、具体的には、スレッドAがローディングされた記憶領域のアドレスをコンテキストとして生成し、該コンテキストをレディーキューに入れることである。レディーキューに積まれているコンテキスト順にスレッドが実行される。すなわち、レディーキューにコンテキストが登録されているスレッドは、実行待ち状態である。
 そして、スケジューラ1721が、共有メモリ1704からスレッド管理テーブル1600を読み出す。スケジューラ1721が、スレッド管理テーブル1600を参照することでスレッドAは排他制御が必要なスレッドであるか否かを判断する。
 スレッドAは排他制御が必要なスレッドであり、遅延可能時間が99[μs]である。なお、遅延可能時刻の算出例については図19で示した処理と同様であるため、ここでの説明は省略する。
 そして、スケジューラ1721が、スレッドAの実行開始指示を受け付ける。スレッドAの実行開始指示を受け付けるとは、たとえば、タスクスイッチを監視することにより、スレッドAが実行待ち状態から実行状態になることを検出する。
 つぎに、スケジューラ1721が、実行時間テーブル1731にアクセスしてスレッドAの実行時間を取得する。ここで、スレッドAの実行時間を70[μs]とする。スケジューラ1721が、スレッドの実行開始指示を受け付けると実行開始指示を受け付けた第2の受付時刻にスレッドAの実行時間を加算することによりスレッドAの予定実行終了時刻を算出する。
 そして、スケジューラ1721が、予定実行終了時刻が遅延可能時刻以降であるか否かを判断する。図21で示すように、ここでは、予定実行終了時刻が遅延可能時刻以降でないと判断される。スケジューラ1721が、予定実行終了時刻が遅延可能時刻以降でないと判断すると、スレッドAとスレッドBとに依存関係があるデータに対してロックをかけずにスレッドAを実行させる。
(実施の形態2にかかるスケジューラ1721による制御処理手順)
 図22は、スケジューラ1721による制御処理手順を示すフローチャートである。まず、スケジューラ1721が、受付部1801により、対象スレッドの生成指示を受け付けたか否かを判断し(ステップS2201)、対象スレッドの生成指示を受け付けていないと判断した場合(ステップS2201:No)、ステップS2201へ戻る。一方、スケジューラ1721が、対象スレッドの生成指示を受け付けたと判断した場合(ステップS2201:Yes)、スレッドの生成指示が受け付けられたスレッドを割り当てるCPUを決定する(ステップS2202)。
 つぎに、スケジューラ1721が、決定したCPUのレディーキューへ対象スレッドを登録し(ステップS2203)、排他判断部1802により、スレッド管理テーブル1600を参照することで排他制御が必要なスレッドであるか否かを判断する(ステップS2204)。まず、スケジューラ1721が、排他制御が必要なスレッドでないと判断した場合(ステップS2204:No)、受付部1801により、実行開始指示を受け付けたか否かを判断する(ステップS2205)。スケジューラ1721が、実行開始指示を受け付けていないと判断した場合(ステップS2205:No)、ステップS2205へ戻る。一方、スケジューラ1721が、実行開始指示を受け付けたと判断した場合(ステップS2205:Yes)、ステップS2211へ移行する。
 また、ステップS2204において、スケジューラ1721が、排他制御が必要なスレッドであると判断した場合(ステップS2204:Yes)、遅延時刻算出部1803により、遅延可能時刻=生成指示を受け付けた第1の受付時刻+対象スレッドの遅延可能時刻とする(ステップS2206)。なお、スケジューラ1721は、遅延可能時刻をスレッド管理テーブル1600から取得することができる。
 つぎに、スケジューラ1721が、受付部1801により、対象スレッドの実行開始指示を受け付けたか否かを判断し(ステップS2207)、対象スレッドの実行開始指示を受け付けていないと判断した場合(ステップS2207:No)、ステップS2207へ戻る。一方、スケジューラ1721が、対象スレッドの実行開始指示を受け付けたと判断した場合(ステップS2207:Yes)、終了時刻算出部1804により、予定実行終了時刻=実行開始指示を受け付けた第2の受付時刻+対象スレッドの実行時間とする(ステップS2208)。なお、スケジューラ1721は、対象スレッドの実行時間を実行時間テーブル1731から取得することができる。
 つぎに、スケジューラ1721が、時刻判断部1805により、予定実行終了時刻が遅延可能時刻以降であるか否かを判断し(ステップS2209)、予定実行終了時刻が遅延可能時刻以降でないと判断した場合(ステップS2209:No)、ステップS2211へ移行する。一方、スケジューラ1721が、予定実行終了時刻が遅延可能時刻以降であると判断した場合(ステップS2209:Yes)、対象スレッドと該対象スレッドの親スレッドに依存関係のあるデータをロックする(ステップS2210)。なお、該データへのロックについては、親スレッドからのアクセスをロックするのであって、対象スレッドからのアクセスについてはロックされない。
 そして、ステップS2205:Yes、ステップS2209:No、またはステップS2210のつぎに、対象スレッドの実行を開始させ(ステップS2211)、ステップS2201へ戻る。
 以上説明したように、検証支援プログラム、検証支援装置、および検証支援方法によれば、シングルコア・マルチスレッド環境において対象スレッドを実行させた場合の生成元スレッドの第1の実行結果と、遅延させて対象スレッドを実行させた場合の生成元スレッドの第2の実行結果とが一致するか否かを判断する。そして、第1の実行結果と第2の実行結果が不一致であれば、対象スレッドと生成元スレッドで依存関係のあるデータに排他制御が必要であることを出力する。これにより、排他制御が必要なスレッドを自動で特定することで、設計者が特定されたスレッドに対してのみセマフォを用意すればよいため、検証対象ソフトウェアに適切にセマフォを用意でき、ソフトウェアの設計を容易化できる。
 また、第1の実行結果と第2の実行結果が一致する場合には、対象スレッドを遅延させる遅延時間を増加して、対象スレッドを、増加した遅延時間遅延させてから実行させる。そして、対象スレッドの実行開始時刻が、生成元スレッドの実行終了時刻以降となるまで遅延時間の増加を繰り返し、第1の実行結果と第2の実行結果が一致するかを判断する。遅延時間を増加させる。これにより、排他制御を用いずに正解値を保証することができる遅延可能時間を自動で特定することができる。製品の運用時に遅延可能時間を用いてスレッド間に依存関係があるデータをロックするか否かを動的に決定することができ、CPUの性能劣化を防止することができる。
 また、第1の実行結果と第2の実行結果が一致し、かつ対象スレッドの実行開始時刻が、生成元スレッドの実行終了時刻以降である場合には、対象スレッドと生成元スレッドで依存関係のあるデータに排他制御が不要である旨の情報を出力する。これにより、排他制御が不要なスレッドを自動で特定することができる。したがって、利用者が、排他制御が不要なスレッドに対してセマフォを用意してしまうことを防止でき、不要な排他制御におけるスピンループ処理によってCPUの性能劣化を防止することができる。
 また、第1の実行結果と第2の実行結果とが一致しない場合に、対象スレッドを遅延させる遅延時間を減らす。そして、対象スレッドを、減らした遅延時間遅延させてから実行させる。これにより、排他制御を用いずに正解値を保証することができる遅延可能時間を見積もることができる。
 以上説明したように、制御プログラム、マルチコアプロセッサシステム、および制御方法によれば、スレッド間で依存関係のあるデータに排他制御を用いずに正解値を保証することができる遅延可能時間に基づいて該データにロックをかけるか否かを動的に判断する。これにより、マルチコアプロセッサの実行状態に応じて排他制御を行うか否かが決まり、不要な排他制御におけるスピンループ処理に起因するCPUの性能劣化を防止することができる。
 なお、実施の形態1で説明した検証支援方法は、あらかじめ用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本検証支援プログラムは、ハードディスク、フレキシブルディスク、CD-ROM、MO、DVD等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本検証支援プログラムは、インターネット等のネットワークを介して配布してもよい。
 200 回路情報
 201 第1のCPUモデル
 202 第2のCPUモデル
 300 検証対象ソフトウェア
 600 検証支援装置
 701 検出部
 702 割り当て部
 703 保持部
 704 実行制御部
 705 一致判断部
 706 時刻判断部
 707 設定部
 708 調整部
 709 出力部
 1700 マルチコアプロセッサシステム
 1721 スケジューラ
 1802 排他判断部
 1803 遅延時刻算出部
 1804 終了時刻算出部
 1805 時刻判断部
 1806 実行制御部

Claims (9)

  1.  第1のコアモデルと第2のコアモデルを備えるマルチコアプロセッサモデルを用いて検証対象ソフトウェアを模擬するコンピュータに、
     前記検証対象ソフトウェアの模擬中に前記第1のコアモデルに割り当てられた生成元スレッドから対象スレッドの生成命令を検出する検出工程と、
     前記検出工程により前記対象スレッドの生成命令が検出された場合、前記第2のコアモデルに前記対象スレッドを割り当てる割り当て工程と、
     前記割り当て工程により前記第2のコアモデルへ前記対象スレッドが割り当てられると、前記対象スレッドを所定遅延時間遅延させてから実行する実行制御工程と、
     前記第1のコアモデル上で、マルチスレッド環境において前記対象スレッドを実行させた場合の前記生成元スレッドの第1の実行結果と、前記実行制御工程により遅延させて前記対象スレッドを実行させた場合の前記生成元スレッドの第2の実行結果とが一致するか否かを判断する一致判断工程と、
     前記一致判断工程により前記第1の実行結果と前記第2の実行結果とが不一致であると判断された場合、前記対象スレッドに排他制御が必要な旨の情報を出力する出力工程と、
     を実行させることを特徴とする検証支援プログラム。
  2.  前記検出工程により前記対象スレッドの生成命令が検出されると、前記対象スレッドの生成命令の一命令前における前記生成元スレッドの実行状態を保持する保持工程と、
     前記一致判断工程により前記第1の実行結果と前記第2の実行結果とが一致すると判断された場合、遅延させた場合の前記対象スレッドの実行開始時刻が前記生成元スレッドの実行終了時刻以降であるか否かを判断する時刻判断工程と、
     前記時刻判断工程により前記対象スレッドの実行開始時刻が前記生成元スレッドの実行終了時刻以降でないと判断された場合、前記保持工程により保持された前記生成元スレッドの実行状態に設定する設定工程と、
     前記所定遅延時間を所定時間長くする調整工程と、を実行させ、
     前記実行制御工程は、
     前記設定工程による設定後の生成元スレッドを実行し、前記対象スレッドを前記調整工程により長くされた所定遅延時間遅延させてから実行することを特徴とする請求項1に記載の検証支援プログラム。
  3.  前記出力工程は、
     前記時刻判断工程により前記対象スレッドの実行開始時刻が前記生成元スレッドの実行終了時刻以降であると判断された場合、前記対象スレッドに排他制御が必要でない旨の情報を出力することを特徴とする請求項2に記載の検証支援プログラム。
  4.  前記設定工程は、
     前記一致判断工程により前記第1の実行結果と前記第2の実行結果とが不一致であると判断された場合、前記生成元スレッドの実行状態を前記保持された前記生成元スレッドの実行状態に設定し、
     前記調整工程は、
     前記所定遅延時間を前記所定時間短くし、
     前記実行制御工程は、
     前記設定工程による設定後の生成元スレッドを実行し、前記対象スレッドを前記調整工程により短くした所定遅延時間遅延させてから実行し、
     前記一致判断工程は、
     前記実行制御工程により前記短くした所定遅延時間遅延させて前記対象スレッドを実行させた場合の前記生成元スレッドの第2の実行結果と、前記第1の実行結果とが一致するか否かを判断し、
     前記出力工程は、
     前記一致判断工程により前記第1の実行結果と前記第2の実行結果とが一致すると判断された場合、前記短くした所定遅延時間を遅延可能時間とし、前記対象スレッドに排他制御が必要な旨の情報に前記遅延可能時間を関連付けて出力することを特徴とする請求項2に記載の検証支援プログラム。
  5.  マルチコアプロセッサのうちの一のコアに、
     対象スレッドの生成指示を受け付けると、前記対象スレッドが排他制御を必要とするスレッドであるか否かを判断する排他判断工程と、
     前記排他判断工程により前記対象スレッドが排他制御を必要とするスレッドであると判断された場合、前記生成指示を受け付けた第1の受付時刻に排他制御が不要な遅延可能時間を加算することにより遅延可能時刻を算出する遅延時刻算出工程と、
     前記第1の受付時刻経過後、前記対象スレッドの実行開始指示を受け付けると、前記実行開始指示を受け付けた第2の受付時刻に前記対象スレッドの実行時間を加算することにより予定実行終了時刻を算出する終了時刻算出工程と、
     前記終了時刻算出工程により算出された予定実行終了時刻が前記遅延時刻算出工程により算出された遅延可能時刻以降であるか否かを判断する時刻判断工程と、
     前記時刻判断工程により前記予定実行終了時刻が前記遅延可能時刻以降であると判断された場合、前記対象スレッドに依存関係がある生成元スレッドのデータをロックしてから前記対象スレッドを前記マルチコアプロセッサのうちの任意のコアで実行させ、前記時刻判断工程により前記予定実行終了時刻が前記遅延可能時刻以降でないと判断された場合、前記対象スレッドを前記任意のコアで実行させる実行制御工程と、
     を実行させることを特徴とする制御プログラム。
  6.  第1のコアモデルと第2のコアモデルを備えるマルチコアプロセッサモデルを用いて検証対象ソフトウェアの模擬中に前記第1のコアモデルに割り当てられた生成元スレッドから対象スレッドの生成命令を検出する検出手段と、
     前記検出手段により前記対象スレッドの生成命令が検出された場合、前記第2のコアモデルに前記対象スレッドを割り当てる割り当て手段と、
     前記割り当て手段により前記第2のコアモデルへ前記対象スレッドが割り当てられると、前記対象スレッドを所定遅延時間遅延させてから実行する実行制御手段と、
     前記第1のコアモデル上で、マルチスレッド環境において前記対象スレッドを実行させた場合の前記生成元スレッドの第1の実行結果と、前記実行制御手段により遅延させて前記対象スレッドを実行させた場合の前記生成元スレッドの第2の実行結果とが一致するか否かを判断する一致判断手段と、
     前記一致判断手段により前記第1の実行結果と前記第2の実行結果とが不一致であると判断された場合、前記対象スレッドに排他制御が必要な旨の情報を出力する出力手段と、
     を備えることを特徴とする検証支援装置。
  7.  対象スレッドの生成指示を受け付けると、前記対象スレッドが排他制御を必要とするスレッドであるか否かを判断する排他判断手段と、
     前記排他判断手段により前記対象スレッドが排他制御を必要とするスレッドであると判断された場合、前記生成指示を受け付けた第1の受付時刻に排他制御が不要な遅延可能時間を加算することにより遅延可能時刻を算出する遅延時刻算出手段と、
     前記第1の受付時刻経過後、前記対象スレッドの実行開始指示を受け付けると、前記実行開始指示を受け付けた第2の受付時刻に前記対象スレッドの実行時間を加算することにより予定実行終了時刻を算出する終了時刻算出手段と、
     前記終了時刻算出手段により算出された予定実行終了時刻が前記遅延時刻算出手段により算出された遅延可能時刻以降であるか否かを判断する時刻判断手段と、
     前記時刻判断手段により前記予定実行終了時刻が前記遅延可能時刻以降であると判断された場合、前記対象スレッドに依存関係がある生成元スレッドのデータをロックしてから前記対象スレッドをマルチコアプロセッサのうちの任意のコアで実行させ、前記時刻判断手段により前記予定実行終了時刻が前記遅延可能時刻以降でないと判断された場合、前記対象スレッドを前記任意のコアで実行させる実行制御手段と、
     を備えることを特徴とするマルチコアプロセッサシステム。
  8.  第1のコアモデルと第2のコアモデルを備えるマルチコアプロセッサモデルを用いて検証対象ソフトウェアを模擬するコンピュータが、
     前記検証対象ソフトウェアの模擬中に前記第1のコアモデルに割り当てられた生成元スレッドから対象スレッドの生成命令を検出する検出工程と、
     前記検出工程により前記対象スレッドの生成命令が検出された場合、前記第2のコアモデルに前記対象スレッドを割り当てる割り当て工程と、
     前記割り当て工程により前記第2のコアモデルへ前記対象スレッドが割り当てられると、前記対象スレッドを所定遅延時間遅延させてから実行する実行制御工程と、
     前記第1のコアモデル上で、マルチスレッド環境において前記対象スレッドを実行させた場合の前記生成元スレッドの第1の実行結果と、前記実行制御工程により遅延させて前記対象スレッドを実行させた場合の前記生成元スレッドの第2の実行結果とが一致するか否かを判断する一致判断工程と、
     前記一致判断工程により前記第1の実行結果と前記第2の実行結果とが不一致であると判断された場合、前記対象スレッドに排他制御が必要な旨の情報を出力する出力工程と、
     を実行することを特徴とする検証支援方法。
  9.  マルチコアプロセッサのうちの一のコアが、
     対象スレッドの生成指示を受け付けると、前記対象スレッドが排他制御を必要とするスレッドであるか否かを判断する排他判断工程と、
     前記排他判断工程により前記対象スレッドが排他制御を必要とするスレッドであると判断された場合、前記生成指示を受け付けた第1の受付時刻に排他制御が不要な遅延可能時間を加算することにより遅延可能時刻を算出する遅延時刻算出工程と、
     前記第1の受付時刻経過後、前記対象スレッドの実行開始指示を受け付けると、前記実行開始指示を受け付けた第2の受付時刻に前記対象スレッドの実行時間を加算することにより予定実行終了時刻を算出する終了時刻算出工程と、
     前記終了時刻算出工程により算出された予定実行終了時刻が前記遅延時刻算出工程により算出された遅延可能時刻以降であるか否かを判断する時刻判断工程と、
     前記時刻判断工程により前記予定実行終了時刻が前記遅延可能時刻以降であると判断された場合、前記対象スレッドに依存関係がある生成元スレッドのデータをロックしてから前記対象スレッドを前記マルチコアプロセッサのうちの任意のコアで実行させ、前記時刻判断工程により前記予定実行終了時刻が前記遅延可能時刻以降でないと判断された場合、前記対象スレッドを前記任意のコアで実行させる実行制御工程と、
     を実行することを特徴とする制御方法。
PCT/JP2010/055290 2010-03-25 2010-03-25 検証支援プログラム、制御プログラム、検証支援装置、マルチコアプロセッサシステム、検証支援方法、および制御方法 WO2011118014A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2010/055290 WO2011118014A1 (ja) 2010-03-25 2010-03-25 検証支援プログラム、制御プログラム、検証支援装置、マルチコアプロセッサシステム、検証支援方法、および制御方法
JP2012506731A JP5423876B2 (ja) 2010-03-25 2010-03-25 検証支援プログラム、検証支援装置、および検証支援方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/055290 WO2011118014A1 (ja) 2010-03-25 2010-03-25 検証支援プログラム、制御プログラム、検証支援装置、マルチコアプロセッサシステム、検証支援方法、および制御方法

Publications (1)

Publication Number Publication Date
WO2011118014A1 true WO2011118014A1 (ja) 2011-09-29

Family

ID=44672605

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/055290 WO2011118014A1 (ja) 2010-03-25 2010-03-25 検証支援プログラム、制御プログラム、検証支援装置、マルチコアプロセッサシステム、検証支援方法、および制御方法

Country Status (2)

Country Link
JP (1) JP5423876B2 (ja)
WO (1) WO2011118014A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5411381B1 (ja) * 2013-06-03 2014-02-12 株式会社 ディー・エヌ・エー サーバ検査システム、サーバ検査装置およびサーバ検査プログラム
WO2017038290A1 (ja) * 2015-08-31 2017-03-09 日立オートモティブシステムズ株式会社 検証システム、検証装置、及び、車両制御装置

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104778115B (zh) * 2014-01-09 2017-08-25 北大方正集团有限公司 互斥检测方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0561734A (ja) * 1991-08-30 1993-03-12 Nippon Telegr & Teleph Corp <Ntt> 並列プログラムの非決定的動作テスト方法
JPH05233323A (ja) * 1992-02-21 1993-09-10 Toshiba Corp 並行プログラムのデバッグ支援装置
JP2009238176A (ja) * 2008-03-28 2009-10-15 Toshiba Corp 情報処理装置およびプログラムの検証方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0561734A (ja) * 1991-08-30 1993-03-12 Nippon Telegr & Teleph Corp <Ntt> 並列プログラムの非決定的動作テスト方法
JPH05233323A (ja) * 1992-02-21 1993-09-10 Toshiba Corp 並行プログラムのデバッグ支援装置
JP2009238176A (ja) * 2008-03-28 2009-10-15 Toshiba Corp 情報処理装置およびプログラムの検証方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5411381B1 (ja) * 2013-06-03 2014-02-12 株式会社 ディー・エヌ・エー サーバ検査システム、サーバ検査装置およびサーバ検査プログラム
WO2017038290A1 (ja) * 2015-08-31 2017-03-09 日立オートモティブシステムズ株式会社 検証システム、検証装置、及び、車両制御装置

Also Published As

Publication number Publication date
JPWO2011118014A1 (ja) 2013-07-04
JP5423876B2 (ja) 2014-02-19

Similar Documents

Publication Publication Date Title
US11748240B2 (en) Scheduling of scenario models for execution within different computer threads and scheduling of memory regions for use with the scenario models
JP4667206B2 (ja) マルチコアモデルシミュレーションプログラム、該プログラムを記録した記録媒体、マルチコアモデルシミュレータ、およびマルチコアモデルシミュレーション方法
CN101681272B (zh) 使用事务来并行化顺序框架
US8191046B2 (en) Checking transactional memory implementations
US8990062B2 (en) Method and program for estimating operation of program
US20100070422A1 (en) Method and device for workflow definition alteration
US10387605B2 (en) System and method for managing and composing verification engines
JP5423876B2 (ja) 検証支援プログラム、検証支援装置、および検証支援方法
Yip et al. The ForeC synchronous deterministic parallel programming language for multicores
Khasanov et al. Implicit data-parallelism in Kahn process networks: Bridging the MacQueen Gap
US9218273B2 (en) Automatic generation of a resource reconfiguring test
KR101745392B1 (ko) 프로그램 분석 장치 및 분석용 프로그램을 기록한 컴퓨터 판독 가능한 저장매체
Busnot et al. Standard-compliant parallel SystemC simulation of loosely-timed transaction level models
Blem et al. Multicore model from abstract single core inputs
Schubert et al. Solutions to IBM POWER8 verification challenges
JP6528433B2 (ja) 設計支援装置、および設計支援方法
US20100070979A1 (en) Apparatus and Methods for Parallelizing Integrated Circuit Computer-Aided Design Software
JP2010049630A (ja) シミュレーション制御プログラム、シミュレーション制御装置、およびシミュレーション制御方法
Jia et al. VeriLin: A Linearizability Checker for Large-Scale Concurrent Objects
Stitt et al. Thread warping: Dynamic and transparent synthesis of thread accelerators
Bajunaid et al. Analytic models of checkpointing for concurrent component-based software systems
US11972193B1 (en) Automatic elastic CPU for physical verification
Long et al. A Simultaneous computing framework for metamodel-based design optimization
WO2011114478A1 (ja) 生成方法、スケジューリング方法、生成プログラム、スケジューリングプログラム、生成装置、および情報処理装置
JP2008269579A (ja) マルチタスク処理装置およびその方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10848407

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012506731

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10848407

Country of ref document: EP

Kind code of ref document: A1