JP2021060707A - Synchronization control system and synchronization control method - Google Patents
Synchronization control system and synchronization control method Download PDFInfo
- Publication number
- JP2021060707A JP2021060707A JP2019183481A JP2019183481A JP2021060707A JP 2021060707 A JP2021060707 A JP 2021060707A JP 2019183481 A JP2019183481 A JP 2019183481A JP 2019183481 A JP2019183481 A JP 2019183481A JP 2021060707 A JP2021060707 A JP 2021060707A
- Authority
- JP
- Japan
- Prior art keywords
- thread
- lock object
- threads
- wait
- waiting
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 46
- 230000001360 synchronised effect Effects 0.000 claims description 29
- 230000007704 transition Effects 0.000 claims description 5
- 230000008569 process Effects 0.000 description 30
- 230000005540 biological transmission Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 238000004891 communication Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 238000007430 reference method Methods 0.000 description 5
- 238000003491 array Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000007616 round robin method Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Abstract
Description
この発明は、複数のプロセッサコアを搭載したコンピュータ上で実行される同期制御システムおよび同期制御方法に関する。 The present invention relates to a synchronous control system and a synchronous control method performed on a computer equipped with a plurality of processor cores.
スレッド間の同期制御方法として、従来型のオペレーティングシステムにおいては、排他制御を伴う共有メモリ参照方式が用いられていた。例えば、特許文献１に記載の発明では、共有メモリを用いて通信を行うとともに、複数のプロセッサから共有メモリにアクセスする際の排他制御のためにセマフォ（排他制御用変数）を用いている。このような構成においては、セマフォを獲得したあとに共有メモリへアクセスし、読み出し又は書き込みを行うことにより、複数のプロセッサからの同時アクセスを禁止し、同時書き込みによるデータ破壊やデータ読み出し中にデータが書き換えられることを防止している。このため、セマフォ獲得失敗時にはポーリングやスピンロックなどでセマフォ解放を待つ必要がある。このような共有メモリ参照方式では、競合発生時のＣＰＵ負荷や排他制御時のバス負荷が大きくなる傾向があり、システム性能に与えるインパクトが大きかった。 In the conventional operating system, a shared memory reference method with exclusive control has been used as a synchronous control method between threads. For example, in the invention described in Patent Document 1, a shared memory is used for communication, and a semaphore (exclusive control variable) is used for exclusive control when accessing the shared memory from a plurality of processors. In such a configuration, by accessing the shared memory after acquiring the semaphore and reading or writing, simultaneous access from multiple processors is prohibited, and data is destroyed by simultaneous writing or data is read during data reading. It prevents it from being rewritten. Therefore, when the semaphore acquisition fails, it is necessary to wait for the semaphore release by polling or spinlock. In such a shared memory reference method, the CPU load when a conflict occurs and the bus load during exclusive control tend to be large, which has a large impact on the system performance.
この点、共有メモリを参照するのではなく、メッセージングにより通信を行うようにすれば、システム全体の高い並列実行性能を実現することができる。例えば、イベント待ちを管理するサーバスレッドをオペレーティングシステムの一部として設け、このサーバスレッドに対してメッセージングを行うことで同期を行うようにすれば、ポーリングやスピンロックを使用せずに通信を行うことができる。ただし、メッセージングそのものの実行時間は、共有メモリ参照方式よりも大きくなる傾向があり、スレッド間の同期や通信が多用される環境では遅延時間の影響が大きくなる可能性があった。 In this respect, if communication is performed by messaging instead of referring to the shared memory, high parallel execution performance of the entire system can be realized. For example, if a server thread that manages event waits is provided as part of the operating system and synchronization is performed by messaging to this server thread, communication can be performed without using polling or spinlock. Can be done. However, the execution time of the messaging itself tends to be longer than that of the shared memory reference method, and the influence of the delay time may be large in an environment where synchronization between threads and communication are frequently used.
そこで、本発明は、最低限のメッセージング回数でスレッド間の同期を制御することができる同期制御システムおよび同期制御方法を提供することを課題とする。 Therefore, it is an object of the present invention to provide a synchronization control system and a synchronization control method capable of controlling synchronization between threads with a minimum number of messagings.
上記した課題を解決するため、第１の発明は、複数のプロセッサコアを搭載したコンピュータ上で実行される同期制御システムであって、異なるプロセッサコアまたは同一のプロセッサコアに割り当てられたスレッド間での同期処理を実行するための共有資源であり、割り当てられた前記プロセッサコアにかかわらずすべてのスレッドがアクセス可能なロックオブジェクトを備え、前記ロックオブジェクトは、前記複数のプロセッサコアごとに、次に起床されるべきスレッドのスレッド識別子を格納可能であり、前記ロックオブジェクトにより待ち状態となったスレッドの待ち状態の解除を行うときに、当該ロックオブジェクトを検索して次に起床する待ち状態のスレッドのスレッド識別子を取得し、当該スレッド識別子を使用したメッセージングによりスレッドを実行可能状態に移行させる。 In order to solve the above-mentioned problems, the first invention is a synchronous control system executed on a computer equipped with a plurality of processor cores, which is between threads assigned to different processor cores or the same processor core. It is a shared resource for performing synchronous processing and includes a lock object that is accessible to all threads regardless of the allocated processor core, and the lock object is then woken up for each of the plurality of processor cores. The thread identifier of the thread to be stored can be stored, and when the waiting state of the thread waiting by the lock object is released, the thread identifier of the waiting thread that searches for the lock object and wakes up next. Is acquired, and the thread is moved to the executable state by messaging using the thread identifier.
また、第２の発明は、複数のプロセッサコアを搭載したコンピュータ上で実行される同期制御方法であって、異なるプロセッサコアまたは同一のプロセッサコアに割り当てられたスレッド間での同期処理を実行するための共有資源であり、割り当てられた前記プロセッサコアにかかわらずすべてのスレッドがアクセス可能なロックオブジェクトを生成するステップと、前記ロックオブジェクトによりスレッドが待ち状態となったときに、前記ロックオブジェクトに当該スレッドのスレッド識別子を登録するステップと、前記ロックオブジェクトにより待ち状態となったスレッドの待ち状態の解除を行うときに、当該ロックオブジェクトを検索して次に起床する待ち状態のスレッドのスレッド識別子を取得し、当該スレッド識別子を使用したメッセージングによりスレッドを実行可能状態に移行させるステップと、を備える。 The second invention is a synchronous control method executed on a computer equipped with a plurality of processor cores, in order to execute synchronous processing between threads assigned to different processor cores or the same processor core. A step to create a lock object that is a shared resource of and accessible to all threads regardless of the allocated processor core, and when a thread is put into a wait state by the lock object, the thread is assigned to the lock object. When the step of registering the thread identifier of the above and the release of the waiting state of the thread waiting by the lock object, the lock object is searched and the thread identifier of the waiting thread that wakes up next is acquired. , A step of migrating a thread to an executable state by messaging using the thread identifier.
本発明は上記の通りであり、最低限のメッセージング回数でスレッド間の同期を制御することができる。 The present invention is as described above, and synchronization between threads can be controlled with a minimum number of messagings.
本発明の実施形態について、図を参照しながら説明する。
本実施形態に係るコンピュータシステムは、図１に示すようなコンピュータを備えている。このコンピュータは、ＣＰＵ１０と、主記憶装置１４と、補助記憶装置（図示せず）と、を備えている。
An embodiment of the present invention will be described with reference to the drawings.
The computer system according to the present embodiment includes a computer as shown in FIG. This computer includes a
本実施形態に係るＣＰＵ１０は、１つのプロセッサパッケージ内に複数のプロセッサコア１１を搭載したマルチコア・プロセッサであり、例えば、第１プロセッサコア１１ａおよび第２プロセッサコア１１ｂの２つのプロセッサコア１１を備えている。なお、本実施形態においては、ＣＰＵ１０が第１プロセッサコア１１ａおよび第２プロセッサコア１１ｂの２つのプロセッサコア１１を備えている例について説明するが、これに限らず、ＣＰＵ１０は３つ以上のプロセッサコア１１を備えていてもよい。
The
主記憶装置１４は、ＣＰＵ１０が直接アクセスすることができる記憶装置であり、実行中のスレッド３０のコンテキストやその他のデータが記憶されている。例えばこの主記憶装置１４には、オペレーティングシステム２０の一部であるマイクロカーネル２１の実体としてのコンテキストデータや、オペレーティングシステム２０によって実行を制御されるスレッド３０の実体としてのコンテキストデータ、スレッド３０によって使用可能な共有メモリ１５、などが配置されている。なお、これらのオペレーティングシステム２０やスレッド３０のプログラムは補助記憶装置に記憶されており、必要に応じて主記憶装置１４に読み込まれることで、ＣＰＵ１０によって使用可能となる。
The main storage device 14 is a storage device that can be directly accessed by the
オペレーティングシステム２０は、ＣＰＵ１０上でのスレッド３０の実行を制御するソフトウェアである。本実施形態に係るオペレーティングシステム２０は、上記した複数のプロセッサコア１１のそれぞれに対応して、複数のマイクロカーネル２１が実行されるように構成されている。マイクロカーネル２１は、オペレーティングシステム２０の核となるものであり、メモリ管理、割り込み要求処理、スレッド間通信などの必要最小限の機能を搭載したカーネルプログラムである。このマイクロカーネル２１は、システム起動時にプロセッサコア１１ごとにインスタンスが生成され、対応するプロセッサコア１１上で常に実行されるようになっている。
The operating system 20 is software that controls the execution of the thread 30 on the
以下の説明においては、第１プロセッサコア１１ａ上で実行されるマイクロカーネル２１のインスタンスを第１マイクロカーネル２１ａと呼び、第２プロセッサコア１１ｂ上で実行されるマイクロカーネル２１のインスタンスを第２マイクロカーネル２１ｂと呼ぶこととする。また、記載を簡略化するため、マイクロカーネル２１のインスタンスを単にマイクロカーネル２１と記載する場合もある。なお、ＣＰＵ１０が３つ以上のプロセッサコア１１を備えている場合には、プロセッサコア１１の数と同数のマイクロカーネル２１のインスタンスが生成され、それぞれのプロセッサコア１１で１つのマイクロカーネル２１が実行されることになる。
In the following description, the instance of the microkernel 21 executed on the first processor core 11a is referred to as the first microkernel 21a, and the instance of the microkernel 21 executed on the second processor core 11b is referred to as the second microkernel. It will be called 21b. Further, in order to simplify the description, the instance of the microkernel 21 may be simply described as the microkernel 21. When the
これらのマイクロカーネル２１は、他のマイクロカーネル２１と通信を行うためのメッセージング機能を有している。マイクロカーネル２１が、このメッセージング機能を使用して相互に通信を行うことで、異なるプロセッサコア１１または同一のプロセッサコア１１に割り当てられたスレッド３０間での同期を実現する同期制御システムが実現されている。この同期制御システムについては後ほど詳述する。 These microkernels 21 have a messaging function for communicating with other microkernels 21. When the microkernel 21 communicates with each other using this messaging function, a synchronization control system that realizes synchronization between threads 30 assigned to different processor cores 11 or the same processor core 11 is realized. There is. This synchronous control system will be described in detail later.
また、これらのマイクロカーネル２１は、当該マイクロカーネル２１が実行されるプロセッサコア１１（以下、マイクロカーネル２１それ自体が実行されるプロセッサコア１１のことを、当該マイクロカーネル２１の「自コア」という）に割り当てられたスレッド３０のスケジューリングを行う。すなわち、マイクロカーネル２１は、予め定められた所定のスケジューリングポリシーに従って、自コアで実行するスレッド３０を選択し、スレッド３０を順番に実行する。なお、スケジューリングポリシーとして何を選択するかは任意に設定可能である。例えば、スレッド３０の優先度順、ラウンドロビン方式、ＦＩＦＯなどの既知のスケジューリングポリシーのうちから最適なものを使用すればよい。 Further, these microkernels 21 are processor cores 11 on which the microkernel 21 is executed (hereinafter, the processor core 11 on which the microkernel 21 itself is executed is referred to as "own core" of the microkernel 21). Schedule the thread 30 assigned to. That is, the microkernel 21 selects threads 30 to be executed in its own core according to a predetermined scheduling policy, and executes threads 30 in order. What is selected as the scheduling policy can be arbitrarily set. For example, the most suitable scheduling policy such as thread 30 priority order, round robin method, and FIFO may be used.
マイクロカーネル２１によるスケジューリングは、具体的には、スレッド３０の状態を遷移させることにより行われる。このスレッド３０の状態としては、少なくとも、「実行状態」「実行可能状態」「待ち状態」がある。「実行状態」は、スレッド３０にプロセッサコア１１が割り当てられて実行している状態である。また、「実行可能状態」は、プロセッサコア１１が割り当てられれば実行できるが、他のスレッド３０がプロセッサコア１１を占有しているため、実行を待機している状態である。また、「待ち状態」は、何らかのイベントが完了するのを待っている状態である。 Specifically, scheduling by the microkernel 21 is performed by transitioning the state of the thread 30. The state of the thread 30 includes at least an "execution state", a "executable state", and a "waiting state". The "execution state" is a state in which the processor core 11 is assigned to the thread 30 and is being executed. Further, the "executable state" can be executed if the processor core 11 is assigned, but is waiting for execution because another thread 30 occupies the processor core 11. The "waiting state" is a state of waiting for some event to be completed.
例えば、スレッド３０は以下のように状態が遷移する。まず、生成されたスレッド３０は、実行可能状態になり、マイクロカーネル２１が管理する実行可能状態のキューに接続される。このキューで最も高い優先順位にあるスレッド３０は、マイクロカーネル２１によってディスパッチされ、実行可能状態から実行状態に遷移する。なお、スレッド３０の実行中に、割込みにより他のスレッド３０に実行権が渡されると、実行中のスレッド３０は実行可能状態に遷移する。また、同期処理などの特定のイベントが発生した場合には、マイクロカーネル２１によってスレッド３０が待ち状態に遷移する。待ち状態に遷移したスレッド３０は、待ち状態が解除されるまで待機し、待ち状態が解除されたら実行可能状態に遷移する。 For example, the state of thread 30 changes as follows. First, the generated thread 30 is put into an executable state and is connected to an executable state queue managed by the microkernel 21. Thread 30, which has the highest priority in this queue, is dispatched by the microkernel 21 to transition from the executable state to the execution state. If the execution right is passed to another thread 30 by an interrupt during the execution of the thread 30, the running thread 30 transitions to the executable state. Further, when a specific event such as synchronization processing occurs, the thread 30 transitions to the waiting state by the microkernel 21. The thread 30 that has transitioned to the wait state waits until the wait state is released, and then transitions to the executable state when the wait state is released.
なお、スレッド３０が生成されると、当該スレッド３０を制御するためにスレッド制御ブロックが生成される。このスレッド制御ブロックは、スレッド３０ごとに１つ生成され、スレッド３０が終了するまでマイクロカーネル２１によって管理される。このスレッド制御ブロックには、上記したスレッド３０の状態や、スレッド３０の優先度などの情報が登録される。本実施形態においては、このスレッド制御ブロックに、後述する待ち管理キューも登録される。 When the thread 30 is generated, a thread control block is generated to control the thread 30. One thread control block is generated for each thread 30, and is managed by the microkernel 21 until the thread 30 ends. Information such as the state of the thread 30 and the priority of the thread 30 is registered in this thread control block. In the present embodiment, the wait management queue described later is also registered in this thread control block.
本実施形態に係るスレッド３０は、基本的に生成されたプロセッサコア１１上で実行される。このため、生成されたプロセッサコア１１上で実行しているマイクロカーネル２１によって制御されることになる。例えば、図１に示すように、第１グループ３１で実行されるスレッド３０は、第１プロセッサコア１１ａ上で第１マイクロカーネル２１ａによって制御されて実行される。また、第２グループ３２で実行されるスレッド３０は、第２プロセッサコア１１ｂ上で第２マイクロカーネル２１ｂによって制御されて実行される。このとき、第１グループ３１で実行されるスレッド３０と第２グループ３２で実行されるスレッド３０とは、互いに直接通信を行うことはできないため、別のグループのスレッド３０間で通信を行う場合には、共有メモリ１５またはマイクロカーネル２１を介して通信を行う必要がある。 The thread 30 according to this embodiment is basically executed on the generated processor core 11. Therefore, it will be controlled by the microkernel 21 running on the generated processor core 11. For example, as shown in FIG. 1, the thread 30 executed in the first group 31 is controlled and executed by the first microkernel 21a on the first processor core 11a. Further, the thread 30 executed in the second group 32 is controlled and executed by the second microkernel 21b on the second processor core 11b. At this time, since the thread 30 executed in the first group 31 and the thread 30 executed in the second group 32 cannot directly communicate with each other, when communicating between the threads 30 of another group. Need to communicate via the shared memory 15 or the microkernel 21.
共有メモリ１５は、すべてのプロセッサコア１１で共有されるメモリ領域である。この共有メモリ１５へは、どのプロセッサコア１１で実行しているスレッド３０であってもアクセス可能である。本実施形態においては、この共有メモリ１５に、複数のロックオブジェクト３５を生成可能である。 The shared memory 15 is a memory area shared by all processor cores 11. The shared memory 15 can be accessed by any thread 30 running on any processor core 11. In the present embodiment, a plurality of lock objects 35 can be generated in the shared memory 15.
ロックオブジェクト３５は、異なるプロセッサコア１１または同一のプロセッサコア１１に割り当てられたスレッド３０間での同期処理を実行するための共有資源である。このロックオブジェクト３５は、共有メモリ１５に生成されるため、割り当てられたプロセッサコア１１にかかわらずすべてのスレッド３０がアクセス可能となっている。また、このロックオブジェクト３５はユーザ空間に生成されるため、空きメモリが存在する限りにおいて無制限に生成可能である。 The lock object 35 is a shared resource for executing synchronous processing between threads 30 assigned to different processor cores 11 or the same processor core 11. Since the lock object 35 is generated in the shared memory 15, all threads 30 can access it regardless of the allocated processor core 11. Further, since the lock object 35 is generated in the user space, it can be generated indefinitely as long as there is free memory.
本実施形態に係るロックオブジェクト３５は、図２に示すような構造体で定義される（構造体名「ｌｏｃｋｏｂｊ」で定義される構造体を参照）。このロックオブジェクト３５は、メンバとして、複数のプロセッサコア１１数分の配列であるスレッド情報格納配列（ｐｅｒｃｐｕ［ＣＯＲＥ＿ＣＯＵＮＴ］；ＣＯＲＥ＿ＣＯＵＮＴはプロセッサコア１１の数を示す定数）を含んでいる。 The lock object 35 according to the present embodiment is defined by a structure as shown in FIG. 2 (see the structure defined by the structure name “lockobj”). As a member, the lock object 35 includes a thread information storage array (percpu [CORE_COUNT]; CORE_COUNT is a constant indicating the number of processor cores 11), which is an array for a plurality of 11 processor cores.
本実施形態に係るスレッド情報格納配列の各要素は、任意のスレッド３０に係るスレッド情報である。このスレッド情報は、図２に示すような構造体で定義される（構造体名「ｌｏｃｋｉｎｆｏ」で定義される構造体を参照）。このスレッド情報は、メンバとして「ｔｉｄ」と「ｐｒｉ」とを含んでいる。また、「ｕｉｎｔ１６＿ｔ」は、これらメンバのデータ型が１６ビットの符号なし整数型であることを示している。なお、「ｔｉｄ」には、任意のスレッド３０を特定するためのスレッド識別子が格納される。また、「ｐｒｉ」には、当該スレッド識別子で特定されるスレッド３０の優先度が格納される。 Each element of the thread information storage array according to the present embodiment is thread information related to an arbitrary thread 30. This thread information is defined by a structure as shown in FIG. 2 (see the structure defined by the structure name "lockinfo"). This thread information includes "ted" and "pri" as members. Further, "wint16_t" indicates that the data type of these members is a 16-bit unsigned integer type. A thread identifier for identifying an arbitrary thread 30 is stored in "tid". Further, the priority of the thread 30 specified by the thread identifier is stored in "pri".
このように、本実施形態に係るスレッド情報（構造体「ｌｏｃｋｉｎｆｏ」）は、メンバとしてスレッド識別子とスレッド優先度とを含んでいる。このスレッド識別子とスレッド優先度とは、アトミックに（一体不可分に）読み書きされる必要がある。このため、このスレッド識別子とスレッド優先度とは、ＣＰＵ１０がアトミックに操作できるサイズとなっている。具体的には、構造体「ｌｏｃｋｉｎｆｏ」のサイズ（スレッド識別子とスレッド優先度とを足したサイズ）が、ＣＰＵ１０のビット数（ＣＰＵ１０が不可分操作可能な最大ビット数）を超えないように設定されている。本実施形態に係るＣＰＵ１０は３２ｂｉｔであるため、スレッド識別子とスレッド優先度とを足したサイズ（本実施形態においては、スレッド識別子もスレッド優先度も１６ｂｉｔの変数であるため、これらを足したサイズは３２ｂｉｔである）が、３２ｂｉｔを超えないように設定されている。このように構成することで、スレッド情報にアクセスする際に排他制御が不要となっている。
As described above, the thread information (structure "lockinfo") according to the present embodiment includes the thread identifier and the thread priority as members. This thread identifier and thread priority need to be read and written atomically (inseparably). Therefore, the thread identifier and the thread priority have a size that allows the
なお、上記した図２においては、Ｃ言語における構造を例に説明しているが、Ｃ言語以外のプログラミング言語であっても、上記したロックオブジェクト３５と同様の構造を定義することにより、プログラミング言語に依存せずに同様の効果を得ることができる。構造体の記述方法も、プログラミング言語に応じて変更可能である。 In FIG. 2 described above, the structure in C language is described as an example, but even in a programming language other than C language, the programming language can be defined by defining the same structure as the lock object 35 described above. The same effect can be obtained without depending on. The description method of the structure can also be changed according to the programming language.
上記したスレッド情報格納配列には、複数のプロセッサコア１１ごとに、次に起床されるべきスレッド３０のスレッド情報が格納される。例えば、プロセッサコア１１が２つの場合には、ｐｅｒｃｐｕ［］の要素数は「２」であり、ｐｅｒｃｐｕ［０］には第１プロセッサコア１１ａにおいて次に起床されるべきスレッド３０に係るスレッド情報が格納され、ｐｅｒｃｐｕ［１］には第２プロセッサコア１１ｂにおいて次に起床されるべきスレッド３０に係るスレッド情報が格納される。なお、プロセッサコア１１が３つ以上の場合も同様に、ｐｅｒｃｐｕ［］の要素数をプロセッサコア１１の数に合わせて設定し、ｐｅｒｃｐｕ［］の各要素に１つずつプロセッサコア１１を割り当てて、当該ｐｅｒｃｐｕ［］の要素に当該プロセッサコア１１において次に起床されるべきスレッド３０に係るスレッド情報を格納すればよい。 In the thread information storage array described above, thread information of the thread 30 to be woken up next is stored for each of the plurality of processor cores 11. For example, when there are two processor cores 11, the number of elements of percpu [] is "2", and percpu [0] contains thread information related to the thread 30 to be woken up next in the first processor core 11a. The thread information related to the thread 30 to be woken up next in the second processor core 11b is stored in the percpu [1]. Similarly, when the number of processor cores 11 is three or more, the number of elements of percpu [] is set according to the number of processor cores 11, and one processor core 11 is assigned to each element of percpu []. The thread information related to the thread 30 to be woken up next in the processor core 11 may be stored in the element of the percpu [].
これにより、ロックオブジェクト３５には、複数のプロセッサコア１１ごとに、次に起床されるべきスレッド３０のスレッド識別子が格納されるようになっている。なお、本実施形態に係るスレッド情報格納配列を構造体「ｌｏｃｋｉｎｆｏ」の配列としたが、これに限らず、ロックオブジェクト３５は少なくとも複数のプロセッサコア１１ごとにスレッド識別子を格納できるものであればよい。例えば、スレッド情報格納配列を数値型の配列として、スレッド識別子のみを格納するようにしてもよい。その他、構造体「ｌｏｃｋｉｎｆｏ」のメンバを図２で示す定義から変更してもよい。 As a result, the lock object 35 stores the thread identifier of the thread 30 to be woken up next for each of the plurality of processor cores 11. The thread information storage array according to the present embodiment is an array of the structure "lockinfo", but the present invention is not limited to this, and the lock object 35 may store a thread identifier for at least a plurality of processor cores 11. .. For example, the thread information storage array may be a numeric type array to store only the thread identifier. In addition, the members of the structure "lockinfo" may be changed from the definition shown in FIG.
上記したロックオブジェクト３５は、同期を必要とするイベントごとに動的に生成可能である。例えば、ロックオブジェクト３５をラップする排他制御用の上位オブジェクト（ミューテックスなど）のインスタンス生成時に合わせて生成することができる。 The lock object 35 described above can be dynamically generated for each event that requires synchronization. For example, it can be generated at the time of instantiation of a higher-level object (mutex or the like) for exclusive control that wraps the lock object 35.
本実施形態に係る同期制御システムは、このロックオブジェクト３５を使用して、異なるプロセッサコア１１または同一のプロセッサコア１１で実行されているスレッド３０間で同期制御を行うことができる。 The synchronous control system according to the present embodiment can use the lock object 35 to perform synchronous control between threads 30 running on different processor cores 11 or the same processor core 11.
すなわち、特定のスレッド３０が、ロックオブジェクト３５を使用した資源待ちとなると、当該ロックオブジェクト３５のスレッド情報格納配列に、待ち状態となったスレッド３０のスレッド識別子が格納される。このとき、スレッド情報格納配列のどの要素に格納されるかは、スレッド３０を実行しているプロセッサコア１１に依存する。すなわち、スレッド３０を実行しているプロセッサコア１１に割り当てられたスレッド情報格納配列の要素に、待ち状態となったスレッド３０のスレッド情報が格納される。 That is, when a specific thread 30 waits for resources using the lock object 35, the thread identifier of the thread 30 in the wait state is stored in the thread information storage array of the lock object 35. At this time, which element of the thread information storage array is stored depends on the processor core 11 executing the thread 30. That is, the thread information of the thread 30 in the waiting state is stored in the element of the thread information storage array assigned to the processor core 11 executing the thread 30.
一方、このようにロックオブジェクト３５により待ち状態となったスレッド３０の待ち状態の解除を行うときには、当該ロックオブジェクト３５を検索して、スレッド情報格納配列に格納されたスレッド識別子を取得し、当該スレッド識別子を使用したメッセージングによりスレッド３０を実行可能状態に移行させる。 On the other hand, when releasing the waiting state of the thread 30 which has been in the waiting state by the lock object 35 in this way, the lock object 35 is searched, the thread identifier stored in the thread information storage array is acquired, and the thread is concerned. The thread 30 is put into an executable state by messaging using an identifier.
以下、上記した同期制御に係る処理フローについて詳しく説明する。なお、本実施形態の同期制御に係る処理フローは、大きく分けて、（１）待ち要求処理、（２）待ち解除要求送信処理、（３）待ち解除要求受信処理、の３つの処理からなるため、以下それぞれについて説明する。 Hereinafter, the processing flow related to the above-mentioned synchronization control will be described in detail. The processing flow related to the synchronization control of the present embodiment is roughly divided into three processes: (1) waiting request processing, (2) waiting release request transmission process, and (3) wait release request reception process. , Each will be described below.
（待ち要求処理）
待ち要求処理は、イベントの終了待ちを行うスレッド３０からの要求を受けて、当該スレッド３０を制御するマイクロカーネル２１（当該スレッド３０が実行されているプロセッサコア１１に割り当てられたマイクロカーネル２１）によって実行される処理である。この待ち要求処理について、図３に示すフローを参照しながら説明する。
(Waiting request processing)
The wait request processing is performed by the microkernel 21 that controls the thread 30 (the microkernel 21 assigned to the processor core 11 on which the thread 30 is executed) in response to a request from the thread 30 that waits for the end of the event. This is the process to be executed. This wait request processing will be described with reference to the flow shown in FIG.
まず、図３に示すステップＳ１００において、マイクロカーネル２１が、任意のスレッド３０（以下、「待ち要求スレッド」という）から待ち要求を受信する。具体的には、待ち要求スレッドが、ロックオブジェクト３５を指定したＡＰＩ呼び出し（後述するｍｆｕｔｅｘ＿ｗａｉｔ（））を行ったときに、マイクロカーネル２１による待ち要求処理が開始される。そして、ステップＳ１０５に進む。 First, in step S100 shown in FIG. 3, the microkernel 21 receives a wait request from an arbitrary thread 30 (hereinafter, referred to as “wait request thread”). Specifically, when the wait request thread makes an API call (mfutex_wait () described later) with the lock object 35 specified, the wait request process by the microkernel 21 is started. Then, the process proceeds to step S105.
ステップＳ１０５では、ステップＳ１００で指定されたロックオブジェクト３５のスレッド情報格納配列を参照し、自コアに対応して格納されたスレッド情報に含まれるスレッド識別子（以下、「格納済ＩＤ」という）を取得する。そして、ステップＳ１１０に進む。 In step S105, the thread information storage array of the lock object 35 specified in step S100 is referred to, and the thread identifier (hereinafter, referred to as “stored ID”) included in the thread information stored corresponding to the own core is acquired. To do. Then, the process proceeds to step S110.
ステップＳ１１０では、格納済ＩＤが有効であるか無効であるかがチェックされる。スレッド情報格納配列にすでにスレッド情報が格納されている場合には格納済ＩＤが有効であるが、スレッド情報格納配列にスレッド情報が格納されていない場合（自コアにおいて、当該ロックオブジェクト３５を使用した待ちスレッド３０が存在しない場合）には格納済ＩＤが無効である。格納済ＩＤが無効である場合（またはスレッド情報格納配列にスレッド情報が格納されていない場合）には、ステップＳ１１５へ進む。一方、格納済ＩＤが有効である場合（すなわちスレッド情報格納配列にスレッド情報が格納されている場合）には、ステップＳ１２０に進む。 In step S110, it is checked whether the stored ID is valid or invalid. If the thread information is already stored in the thread information storage array, the stored ID is valid, but if the thread information is not stored in the thread information storage array (the lock object 35 was used in the own core). The stored ID is invalid (when the waiting thread 30 does not exist). If the stored ID is invalid (or the thread information is not stored in the thread information storage array), the process proceeds to step S115. On the other hand, if the stored ID is valid (that is, the thread information is stored in the thread information storage array), the process proceeds to step S120.
ステップＳ１１５に進んだ場合、自コアにおいて当該ロックオブジェクト３５により待ち状態となったスレッド３０群を管理するための待ち管理キューを生成し、この待ち管理キューを、待ち要求スレッドに係るスレッド制御ブロックに登録する。また、この待ち管理キューに、待ち要求スレッドに係るスレッド制御ブロックを挿入する。これにより、待ち要求スレッドと待ち管理キューとが相互にリンクされる。そして、ステップＳ１２５に進む。 When the process proceeds to step S115, a wait management queue for managing the threads 30 group in the wait state by the lock object 35 is generated in the local core, and this wait management queue is used as a thread control block related to the wait request thread. sign up. In addition, a thread control block related to the wait request thread is inserted into this wait management queue. As a result, the wait request thread and the wait management queue are linked to each other. Then, the process proceeds to step S125.
ステップＳ１２０に進んだ場合、格納済みＩＤで特定されるスレッド３０に係るスレッド制御ブロックを参照し、当該スレッド制御ブロックに登録された待ち管理キューを取得する。そして、この待ち管理キューを、待ち要求スレッドに係るスレッド制御ブロックに登録する。また、この待ち管理キューに、当該スレッド制御ブロックを挿入する。これにより、待ち要求スレッドと待ち管理キューとが相互にリンクされる。そして、ステップＳ１２５に進む。 When the process proceeds to step S120, the thread control block related to the thread 30 specified by the stored ID is referred to, and the wait management queue registered in the thread control block is acquired. Then, this wait management queue is registered in the thread control block related to the wait request thread. In addition, the thread control block is inserted into this wait management queue. As a result, the wait request thread and the wait management queue are linked to each other. Then, the process proceeds to step S125.
ステップＳ１２５では、待ち管理キューを検索し、次に起床されるべきスレッド３０（待ち管理キューに登録されたスレッド３０の中で最も先に起床されるべきスレッド３０）を取得する。次に起床されるべきスレッド３０は、所定の待ち解除ポリシーに従って決定される。待ち解除ポリシーとしてどのようなポリシーを使用するかは任意であるが、本実施形態においては、スレッド３０の優先度順に待ち解除を行うようにしている。すなわち、待ち管理キューに登録されたすべてのスレッド制御ブロックを検索し、最も優先度の高いスレッド３０を選択する。そして、ステップＳ１３０に進む。 In step S125, the wait management queue is searched, and the thread 30 to be woken up next (the thread 30 to be woken up first among the threads 30 registered in the wait management queue) is acquired. The thread 30 to be woken up next is determined according to a predetermined release policy. What kind of policy is used as the wait release policy is arbitrary, but in the present embodiment, the wait release is performed in the order of priority of the thread 30. That is, all the thread control blocks registered in the wait management queue are searched, and the thread 30 having the highest priority is selected. Then, the process proceeds to step S130.
なお、待ち解除ポリシーとしては、スレッド３０の優先度順に限らず、別のポリシーを設定することも可能である。例えば、ＦＩＦＯ（先入れ先出し方式）を使用してもよいし、特定の属性を有するスレッド３０（例えば、書き込みロックを獲得しているライター・スレッド３０）を優先的に待ち解除するようにしてもよい。 The wait release policy is not limited to the order of priority of the thread 30, and another policy can be set. For example, a FIFO (first-in first-out method) may be used, or a thread 30 having a specific attribute (for example, a writer thread 30 that has acquired a write lock) may be preferentially released from the wait.
ステップＳ１３０では、ステップＳ１２５で取得した、次に起床されるべきスレッド３０のスレッド情報（スレッド識別子およびスレッド優先度）を、ロックオブジェクト３５のスレッド情報格納配列（自コアに対応するスレッド情報格納配列の要素）に格納する。なお、ステップＳ１２５で取得したスレッド情報がすでにスレッド情報格納配列に格納されている場合には、スレッド情報格納配列の書き換えを行う必要はない。そして、ステップＳ１３５に進む。 In step S130, the thread information (thread identifier and thread priority) of the thread 30 to be woken up next, which is acquired in step S125, is stored in the thread information storage array of the lock object 35 (the thread information storage array corresponding to the own core). Store in element). If the thread information acquired in step S125 is already stored in the thread information storage array, it is not necessary to rewrite the thread information storage array. Then, the process proceeds to step S135.
ステップＳ１３５では、待ち要求スレッドを「待ち状態」に移行させる。これにより、待ち要求スレッドは、待ち状態が解除されるまで実行されることはない。以上で、処理が終了する。 In step S135, the waiting request thread is moved to the "waiting state". As a result, the wait request thread is not executed until the wait state is released. This completes the process.
（待ち解除要求送信処理）
待ち解除要求送信処理は、同期に係るイベントを終了したスレッド３０からの要求を受けて、当該スレッド３０を制御するマイクロカーネル２１（当該スレッド３０が実行されているプロセッサコア１１に割り当てられたマイクロカーネル２１）によって実行される処理である。すなわち、ロックオブジェクト３５を解放して、次のスレッド３０に実行権を明け渡すべく実行される処理である。この待ち解除要求送信処理について、図４に示すフローを参照しながら説明する。
(Waiting cancellation request transmission processing)
The wait release request transmission process receives a request from the thread 30 that has terminated the event related to synchronization, and receives a request from the thread 30 and controls the microkernel 21 (the microkernel assigned to the processor core 11 on which the thread 30 is executed). This is the process executed by 21). That is, it is a process executed to release the lock object 35 and surrender the execution right to the next thread 30. This wait release request transmission process will be described with reference to the flow shown in FIG.
まず、図４に示すステップＳ２００において、マイクロカーネル２１が、任意のスレッド３０（以下、「待ち解除スレッド」という）から待ち要求を受信する。この待ち要求においては、起床するスレッド３０（実行権の明け渡し先のスレッド３０）のスレッド識別子と、ロックオブジェクト３５と、が指定されている。具体的には、待ち解除スレッドが、起床するスレッド３０のスレッド識別子とロックオブジェクト３５とを指定したＡＰＩ呼び出し（後述するｍｆｕｔｅｘ＿ｗａｋｅ（ｔｉｄ，ｌｏｃｋｏｂｊ））を行ったときに、マイクロカーネル２１により待ち解除要求処理が開始される。そして、ステップＳ２０５に進む。 First, in step S200 shown in FIG. 4, the microkernel 21 receives a wait request from an arbitrary thread 30 (hereinafter, referred to as “wait release thread”). In this wait request, the thread identifier of the thread 30 to wake up (the thread 30 to which the execution right is surrendered) and the lock object 35 are specified. Specifically, when the wait release thread makes an API call (mfutex_wake (tid, lockobj) described later) that specifies the thread identifier of the thread 30 to wake up and the lock object 35, the microkernel 21 requests the wait release. Processing is started. Then, the process proceeds to step S205.
ステップＳ２０５では、ステップＳ２００で取得したスレッド識別子を基に（例えば、ステップＳ２００で取得したスレッド識別子と、ロックオブジェクト３５のスレッド情報格納配列の要素とを比較し）、起床するスレッド３０を実行中のプロセッサコア１１を特定する。そして、当該プロセッサコア１１に係るスレッド３０群を管理するマイクロカーネル２１に対し、待ち解除のメッセージを送信する。本実施形態に係るオペレーティングシステム２０は、複数のプロセッサコア１１ごとに配置されたマイクロカーネル２１間でのメッセージング機能を備えており、このメッセージング機能によって、待ち解除のメッセージが送信される。 In step S205, the thread 30 that wakes up is being executed based on the thread identifier acquired in step S200 (for example, comparing the thread identifier acquired in step S200 with the element of the thread information storage array of the lock object 35). Identify the processor core 11. Then, a wait release message is transmitted to the microkernel 21 that manages the thread 30 group related to the processor core 11. The operating system 20 according to the present embodiment has a messaging function between microkernels 21 arranged for each of a plurality of processor cores 11, and a wait release message is transmitted by this messaging function.
メッセージが送信されると、メッセージ送信先のマイクロカーネル２１によって、後述する待ち解除要求受信処理が実行される。メッセージが受け入れられて、待ち解除要求送信処理が開始されると、送信先から回答が来るため、この回答を受け取って処理が終了する。なお、送信先においてメッセージが受け入れられなかった場合（起床するスレッド３０がロックオブジェクト３５を待機していない場合）、送信先は失敗情報とともに回答を送信する。この場合は、ロックオブジェクト３５を再度スキャンして、別の適切なターゲット（起床するスレッド３０）を決定し、待ち解除のメッセージを送信することになる。 When the message is transmitted, the microkernel 21 of the message transmission destination executes the wait release request reception process described later. When the message is accepted and the wait release request transmission process is started, a reply comes from the destination, and the process ends after receiving this reply. If the message is not accepted at the destination (when the wake-up thread 30 is not waiting for the lock object 35), the destination sends a reply together with the failure information. In this case, the lock object 35 will be scanned again to determine another suitable target (thread 30 to wake up) and send a wait release message.
（待ち解除要求受信処理）
待ち解除要求受信処理は、上記した待ち解除のメッセージを受信したマイクロカーネル２１（起床するスレッド３０が実行されているプロセッサコア１１に割り当てられたマイクロカーネル２１）によって実行される処理である。この待ち解除要求受信処理について、図５に示すフローを参照しながら説明する。
まず、図５に示すステップＳ３００において、マイクロカーネル２１が、上記した待ち解除のメッセージを受信する。そして、ステップＳ３０５に進む。
(Waiting cancellation request reception processing)
The wait release request reception process is a process executed by the microkernel 21 (the microkernel 21 assigned to the processor core 11 on which the wake-up thread 30 is executed) that has received the wait release message. This wait release request reception process will be described with reference to the flow shown in FIG.
First, in step S300 shown in FIG. 5, the microkernel 21 receives the above-mentioned release message. Then, the process proceeds to step S305.
ステップＳ３０５では、起床するスレッド３０を待ち管理キューから除外する。すなわち、起床するスレッド３０に係るスレッド制御ブロックに登録された待ち管理キューを取得し、当該待ち管理キューから、起床するスレッド３０に係るスレッド制御ブロックを削除する。待ち管理キューは、共通のロックオブジェクト３５に起因して待機している複数のスレッド３０群（同じプロセッサコア１１で実行されているスレッド３０群）で共有されているため、これらのスレッド３０群に係るスレッド制御ブロックに登録された待ち管理キューからも、起床するスレッド３０に係るスレッド制御ブロックが削除されることになる。そして、ステップＳ３１０に進む。 In step S305, the wake-up thread 30 is excluded from the wait management queue. That is, the wait management queue registered in the thread control block related to the wake-up thread 30 is acquired, and the thread control block related to the wake-up thread 30 is deleted from the wait management queue. Since the wait management queue is shared by a plurality of threads 30 groups waiting due to the common lock object 35 (threads 30 groups running on the same processor core 11), these threads 30 groups The thread control block related to the wake-up thread 30 is also deleted from the wait management queue registered in the thread control block. Then, the process proceeds to step S310.
ステップＳ３１０では、ステップＳ３０５で取得した待ち管理キューを検索し、今回起床するスレッド３０の次に起床されるべきスレッド３０に係るスレッド制御ブロックを選択する。このとき、次に起床されるべきスレッド３０は、図３のステップＳ１２５と同様に、所定の待ち解除ポリシーに従って決定される。そして、ステップＳ３１５に進む。 In step S310, the wait management queue acquired in step S305 is searched, and the thread control block related to the thread 30 to be woken up next to the thread 30 to wake up this time is selected. At this time, the thread 30 to be woken up next is determined according to a predetermined wait release policy, as in step S125 of FIG. Then, the process proceeds to step S315.
ステップＳ３１５では、ステップＳ３１０で選択した、次に起床されるべきスレッド３０に係るスレッド情報（スレッド識別子およびスレッド優先度）を、ロックオブジェクト３５のスレッド情報格納配列（自コアに対応するスレッド情報格納配列の要素）に格納する。なお、ステップＳ３１０において、待ち管理キューにスレッド３０が存在しなかった場合には、自コアに対応するスレッド情報格納配列の要素に、無効なスレッド情報（または、無効なスレッド識別子を含むスレッド情報）を格納する。そして、ステップＳ３２０に進む。
ステップＳ３２０では、起床するスレッド３０のステータスを「実行可能状態」に移行する。そして、ステップＳ３２５に進む。
ステップＳ３２５では、起床するスレッド３０をディスパッチし、「実行状態」に移行させる。以上で、処理が終了する。
In step S315, the thread information (thread identifier and thread priority) related to the thread 30 to be woken up next selected in step S310 is stored in the thread information storage array of the lock object 35 (thread information storage array corresponding to the own core). Element). If the thread 30 does not exist in the wait management queue in step S310, invalid thread information (or thread information including an invalid thread identifier) is included in the element of the thread information storage array corresponding to the own core. To store. Then, the process proceeds to step S320.
In step S320, the status of the wake-up thread 30 is changed to the “executable state”. Then, the process proceeds to step S325.
In step S325, the wake-up thread 30 is dispatched to move to the “execution state”. This completes the process.
（待ち要求処理のシーケンス）
次に、上記した待ち要求処理において、スレッド３０およびマイクロカーネル２１間でどのようなやり取りが発生するのかを、図６に示すシーケンス図を用いて説明する。この図６では、スレッドＡが、何らかのイベント待ちとなる様子を示している。例えば、スレッドＡが、ミューテックスの獲得に失敗して待ち状態となる場合などである。
(Waiting request processing sequence)
Next, in the above-mentioned wait request processing, what kind of exchange occurs between the thread 30 and the microkernel 21 will be described with reference to the sequence diagram shown in FIG. FIG. 6 shows how thread A waits for some event. For example, the thread A fails to acquire the mutex and is in a waiting state.
スレッドＡがミューテックスの獲得に失敗すると、そのミューテックスの下位オブジェクトであるロックオブジェクト３５を使用して待ち要求が発行される。本実施形態に係る待ち要求は、ｍｆｕｔｅｘ＿ｗａｉｔ（）という、オペレーティングシステム２０のＡＰＩ（システムコール）として設けられている。ｍｆｕｔｅｘ＿ｗａｉｔ（）では、引数としてロックオブジェクト３５が渡される。 If thread A fails to acquire the mutex, a wait request is issued using the lock object 35, which is a subordinate object of the mutex. The wait request according to the present embodiment is provided as an API (system call) of the operating system 20 called mfutex_wait (). In mfutex_wait (), the lock object 35 is passed as an argument.
ｍｆｕｔｅｘ＿ｗａｉｔ（）が呼び出されると、スレッドＡを管理するマイクロカーネル２１（ここでは第１マイクロカーネル２１ａ）による処理が開始される。第１マイクロカーネル２１ａは、図３で説明したように、ロックオブジェクト３５を参照して、ロックオブジェクト３５の解放を待っている自コアのスレッド３０が既に存在するか否かをチェックする。そして、そのチェック結果に応じて、ロックオブジェクト３５や待ち管理キューの内容を適切に書き換える。そして、スレッドＡを「待ち状態」に移行させる。 When mfutex_wait () is called, processing by the microkernel 21 (here, the first microkernel 21a) that manages thread A is started. As described with reference to FIG. 3, the first microkernel 21a refers to the lock object 35 and checks whether or not the thread 30 of its own core waiting for the release of the lock object 35 already exists. Then, the contents of the lock object 35 and the wait management queue are appropriately rewritten according to the check result. Then, the thread A is moved to the "waiting state".
（待ち要求解除処理のシーケンス）
次に、上記した待ち解除要求送信処理および待ち解除要求受信処理において、スレッド３０およびマイクロカーネル２１間でどのようなやり取りが発生するのかを、図７に示すシーケンス図を用いて説明する。この図７では、ロックオブジェクト３５に係る実行権が、第２プロセッサコア１１ｂで実行中のスレッドＢから、第１プロセッサコア１１ａで実行中のスレッドＡへと受け渡される様子を示している。例えば、スレッドＢがミューテックスを解放したことにより、スレッドＡがミューテックスを獲得する場合などである。
(Sequence of waiting request cancellation processing)
Next, what kind of exchange occurs between the thread 30 and the microkernel 21 in the above-mentioned wait release request transmission process and wait release request reception process will be described with reference to the sequence diagram shown in FIG. 7. FIG. 7 shows how the execution right related to the lock object 35 is transferred from the thread B executing on the second processor core 11b to the thread A executing on the first processor core 11a. For example, when thread B releases the mutex, thread A acquires the mutex.
スレッドＢがミューテックスを解放したときには、まず、実行権を受け渡す先のスレッド３０を決定する。本実施形態に係る待ち解除ポリシーは、スレッド３０の優先度順であるため、ミューテックスの下位オブジェクトであるロックオブジェクト３５のスレッド情報格納配列を検索し、最も優先度の高いスレッド３０のスレッド識別子を取得する（スレッド情報格納配列に格納されたスレッド情報のスレッド優先度をすべてチェックし、最も優先度の高いスレッド情報に係るスレッド識別子を取得する）。そして、そのスレッド識別子とロックオブジェクト３５とを使用して、待ち解除要求を発行する。本実施形態に係る待ち解除要求は、ｍｆｕｔｅｘ＿ｗａｋｅ（）という、オペレーティングシステム２０のＡＰＩ（システムコール）として設けられている。このｍｆｕｔｅｘ＿ｗａｋｅ（）は、引数として、スレッド識別子とロックオブジェクト３５とを指定するようになっている。 When thread B releases the mutex, it first determines the thread 30 to which the execution right is to be delivered. Since the wait release policy according to the present embodiment is in the order of priority of the thread 30, the thread information storage array of the lock object 35, which is a lower object of the mutex, is searched, and the thread identifier of the thread 30 having the highest priority is acquired. (Checks all thread priorities of thread information stored in the thread information storage array and obtains the thread identifier related to the thread information with the highest priority). Then, the wait release request is issued using the thread identifier and the lock object 35. The wait release request according to the present embodiment is provided as an API (system call) of the operating system 20 called mfutex_wake (). This mfutex_wake () specifies a thread identifier and a lock object 35 as arguments.
ｍｆｕｔｅｘ＿ｗａｋｅ（）が呼び出されると、スレッドＢを管理するマイクロカーネル２１（ここでは第２マイクロカーネル２１ｂ）による処理が開始される。第２マイクロカーネル２１ｂは、図４で説明したように、実行権を受け渡す先のスレッド３０（ここではスレッドＡ）を管理するマイクロカーネル２１（ここでは第１マイクロカーネル２１ａ）に対し、待ち解除のメッセージを送信する。このメッセージングは、例えば、待ち解除のメッセージであることを示す識別子（図７では、ＭＦＵＴＥＸ＿ＷＡＫＥで定義された定数）、起床するスレッド３０のスレッド識別子、ロックオブジェクト３５を指定して実行される。 When mfutex_wake () is called, processing by the microkernel 21 (here, the second microkernel 21b) that manages thread B is started. As described with reference to FIG. 4, the second microkernel 21b cancels the wait for the microkernel 21 (here, the first microkernel 21a) that manages the thread 30 (here, thread A) to which the execution right is transferred. Message. This messaging is executed by designating, for example, an identifier indicating that the message is a wait release message (in FIG. 7, a constant defined by MFUTEX_WAKE), a thread identifier of the thread 30 to wake up, and a lock object 35.
このメッセージを第１マイクロカーネル２１ａが受信すると、図５で説明したように、ロックオブジェクト３５や待ち管理キューの登録内容を適切に書き換える。そして、スレッドＡを「実行可能状態」に移行させる。その後、所定のスケジューリングポリシーに従い、スレッドＡをディスパッチしたときに、スレッドＡが第１マイクロカーネル２１ａによって実行される。 When this message is received by the first microkernel 21a, the registered contents of the lock object 35 and the wait management queue are appropriately rewritten as described with reference to FIG. Then, the thread A is moved to the "executable state". Then, when thread A is dispatched according to a predetermined scheduling policy, thread A is executed by the first microkernel 21a.
なお、上記の説明では、ロックオブジェクト３５に係る実行権が、第２プロセッサコア１１ｂで実行中のスレッドＢから、第１プロセッサコア１１ａで実行中のスレッドＡへと受け渡される例について説明した。すなわち、異なるプロセッサコア１１に割り当てられたスレッド３０間での同期処理について説明した。しかしながら、これに限らず、ロックオブジェクト３５に係る実行権が、同じプロセッサコア１１内で受け渡されるようにしてもよい。すなわち、同一のプロセッサコア１１に割り当てられたスレッド３０間で同期処理を行うようにしてもよい（例えば、図７に示すスレッドＡとスレッドＢとが同じプロセッサコア１１内で実行されていてもよい）。 In the above description, an example in which the execution right related to the lock object 35 is transferred from the thread B executing on the second processor core 11b to the thread A executing on the first processor core 11a has been described. That is, the synchronous processing between the threads 30 assigned to the different processor cores 11 has been described. However, the present invention is not limited to this, and the execution right related to the lock object 35 may be passed within the same processor core 11. That is, synchronous processing may be performed between threads 30 assigned to the same processor core 11 (for example, thread A and thread B shown in FIG. 7 may be executed in the same processor core 11. ).
（まとめ）
本実施形態は上記の通りであり、割り当てられたプロセッサコア１１にかかわらずすべてのスレッド３０がアクセス可能な共有資源のロックオブジェクト３５を備え、このロックオブジェクト３５は、複数のプロセッサコア１１ごとに、次に起床されるべきスレッド３０のスレッド識別子を格納可能である。そして、ロックオブジェクト３５により待ち状態となったスレッド３０の待ち状態の解除を行うときには、当該ロックオブジェクト３５を検索して次に起床する待ち状態のスレッド３０のスレッド識別子を取得し、当該スレッド識別子を使用したメッセージングによりスレッド３０を実行可能状態に移行させるようにしている。このため、最低限のメッセージング回数でスレッド３０間の同期を制御することができる。
(Summary)
The present embodiment is as described above, and includes a shared resource lock object 35 that can be accessed by all threads 30 regardless of the allocated processor core 11, and the lock object 35 is provided for each of the plurality of processor cores 11. The thread identifier of the thread 30 to be woken up next can be stored. Then, when releasing the waiting state of the thread 30 which has been in the waiting state by the lock object 35, the lock object 35 is searched, the thread identifier of the thread 30 in the waiting state which wakes up next is acquired, and the thread identifier is used. Thread 30 is moved to an executable state by the messaging used. Therefore, synchronization between threads 30 can be controlled with the minimum number of messagings.
また、このような態様によれば、共有メモリ参照方式と比較して以下の優位性がある。すなわち、共有メモリ参照方式においては、複数のプロセッサコア１１から共有メモリ１５にアクセスする際の排他制御においてセマフォやミューテックスの獲得失敗時にはポーリングやスピンロックなどでオブジェクトの解放を待つ必要がある。しかしながら、本発明によれば、メッセージングにより同期制御を行うため、ポーリングやスピンロックを使用せずに同期制御を行うことができる。よって、競合発生時に無駄なＣＰＵリソースを消費することがなく、また、排他制御時のバス負荷も低下させることができる。 Further, according to such an aspect, there are the following advantages as compared with the shared memory reference method. That is, in the shared memory reference method, it is necessary to wait for the release of the object by polling, spinlock, or the like when the acquisition of the semaphore or mutex fails in the exclusive control when accessing the shared memory 15 from the plurality of processor cores 11. However, according to the present invention, since synchronous control is performed by messaging, synchronous control can be performed without using polling or spinlock. Therefore, wasteful CPU resources are not consumed when a conflict occurs, and the bus load during exclusive control can be reduced.
また、このような態様によれば、従来のメッセージングによる同期制御と比較して以下の優位性がある。すなわち、従来のメッセージングによる同期制御においては、サーバスレッドを介して同期制御を行うため、サーバスレッドを経由する分だけメッセージング回数が増加し、また、サーバスレッドを設けることで資源が消費されていた。この点、本実施形態によれば、共有資源のロックオブジェクト３５を使用することで、サーバスレッドを介さずに同期制御を実行することができる。よって、メッセージング回数を減少させ、スレッド資源を節約することができる。また、ロックオブジェクト３５がユーザ空間に配置されるため、サーバスレッドの静的なコンフィギュレーションに依存せず、空きメモリが存在する限りは無制限でロックオブジェクト３５を生成することができる。すなわち、ロックオブジェクト３５を使用した同期制御のイベント数について、実質的に制限がない。 Further, according to such an aspect, there are the following advantages as compared with the conventional synchronization control by messaging. That is, in the conventional synchronous control by messaging, since the synchronous control is performed via the server thread, the number of messagings increases by the amount of passing through the server thread, and resources are consumed by providing the server thread. In this regard, according to the present embodiment, by using the lock object 35 of the shared resource, synchronization control can be executed without going through the server thread. Therefore, the number of messagings can be reduced and thread resources can be saved. Further, since the lock object 35 is arranged in the user space, the lock object 35 can be generated indefinitely as long as the free memory exists, without depending on the static configuration of the server thread. That is, there is virtually no limit to the number of synchronous control events using the lock object 35.
また、従来の排他制御として、グローバルロックを使用してすべてのプロセッサコア１１が同じクリティカルセクションに入ることができないように制御するものがある。しかしながら、本実施形態によれば、ロックを解除するスレッド３０とロックを獲得しているスレッド３０によって使用されるプロセッサコア１１のみが排他制御にかかわるため、排他制御にかかわらないプロセッサコア１１の処理能力を低下させることがない。 Further, as a conventional exclusive control, there is one that uses a global lock to control all processor cores 11 so that they cannot enter the same critical section. However, according to the present embodiment, since only the thread 30 for releasing the lock and the processor core 11 used by the thread 30 for acquiring the lock are involved in the exclusive control, the processing capacity of the processor core 11 not involved in the exclusive control is involved. Does not reduce.
なお、上記した実施形態においては、待ち解除ポリシーとしてスレッド３０の優先度順を用いているため、スレッド情報格納配列にスレッド３０の優先度を格納した。しかしながら、待ち解除ポリシーとしてスレッド３０の優先度順を用いない場合には、スレッド情報格納配列にスレッド３０の優先度を格納する必要はない。例えば、待ち解除ポリシーとしてＦＩＦＯ（先入れ先出し方式）を用いる場合、スレッド情報格納配列には最低限の情報としてスレッド識別子が格納されていればよい。そして、待ち管理キューの先頭のスレッド３０に係るスレッド識別子をスレッド情報格納配列に格納すればよい。また、どのプロセッサコア１１に係るスレッド３０の待ち解除を行うのかについても、任意のルールを設定可能である。例えば、配列を順番に参照するようにした場合、待ち解除要求を送信するプロセッサコア１１に係るスレッド情報格納配列の添字がｎ（ｎは、ｎ＜ＣＯＲＥ＿ＣＯＵＮＴを満たす非負整数）である場合、スレッド情報格納配列の添字がｍ（ｍは、ｎ＋１＝ＣＯＲＥ＿ＣＯＵＮＴのときには「０」、それ以外のときには「ｎ＋１」）のプロセッサコア１１に係るスレッド３０に待ち解除要求を送信するようにしてもよい。 In the above-described embodiment, since the priority order of threads 30 is used as the wait release policy, the priority of threads 30 is stored in the thread information storage array. However, when the priority order of threads 30 is not used as the wait release policy, it is not necessary to store the priority of threads 30 in the thread information storage array. For example, when a FIFO (first-in first-out method) is used as the wait release policy, the thread identifier may be stored as the minimum information in the thread information storage array. Then, the thread identifier related to the thread 30 at the head of the wait management queue may be stored in the thread information storage array. Further, an arbitrary rule can be set as to which processor core 11 the thread 30 is to be released from the wait. For example, when the arrays are referred to in order, if the subscript of the thread information storage array related to the processor core 11 that sends the wait release request is n (n is a non-negative integer that satisfies n <CORE_COUNT), the thread information. The wait release request may be transmitted to the thread 30 related to the processor core 11 in which the subscript of the storage array is m (m is "0" when n + 1 = CORE_COUNT, and "n + 1" in other cases).
１０ ＣＰＵ
１１ プロセッサコア
１１ａ 第１プロセッサコア
１１ｂ 第２プロセッサコア
１４ 主記憶装置
１５ 共有メモリ
２０ オペレーティングシステム
２１ マイクロカーネル
２１ａ 第１マイクロカーネル
２１ｂ 第２マイクロカーネル
３０ スレッド
３１ 第１グループ
３２ 第２グループ
３５ ロックオブジェクト
10 CPU
11 Processor core 11a 1st processor core 11b 2nd processor core 14 Main memory 15 Shared memory 20 Operating system 21 Microkernel 21a 1st microkernel 21b 2nd microkernel 30 threads 31 1st group 32 2nd group 35 Lock object
Claims (12)
異なるプロセッサコアまたは同一のプロセッサコアに割り当てられたスレッド間での同期処理を実行するための共有資源であり、割り当てられた前記プロセッサコアにかかわらずすべてのスレッドがアクセス可能なロックオブジェクトを備え、
前記ロックオブジェクトは、前記複数のプロセッサコアごとに、次に起床されるべきスレッドのスレッド識別子を格納可能であり、
前記ロックオブジェクトにより待ち状態となったスレッドの待ち状態の解除を行うときに、当該ロックオブジェクトを検索して次に起床する待ち状態のスレッドのスレッド識別子を取得し、当該スレッド識別子を使用したメッセージングによりスレッドを実行可能状態に移行させる、同期制御システム。 A synchronous control system that runs on a computer with multiple processor cores.
A shared resource for performing synchronization between threads assigned to different processor cores or the same processor core, with a lock object accessible to all threads regardless of the assigned processor core.
The lock object can store the thread identifier of the thread to be woken up next for each of the plurality of processor cores.
When releasing the waiting state of a thread that has been in the waiting state by the lock object, the lock object is searched for, the thread identifier of the waiting thread that wakes up next is acquired, and the thread identifier is used for messaging. A synchronous control system that transitions threads to an executable state.
前記スレッド情報格納配列に、前記ロックオブジェクトにより待ち状態となったスレッドのスレッド識別子を格納する、請求項１記載の同期制御システム。 The lock object includes a thread information storage array which is an array for the number of the plurality of processor cores.
The synchronization control system according to claim 1, wherein the thread identifier of the thread waiting by the lock object is stored in the thread information storage array.
前記ロックオブジェクトにより待ち状態となったスレッドに係る前記スレッド制御ブロックには、同じロックオブジェクトにより待ち状態となったスレッド群を管理するための待ち管理キューが登録される、請求項１〜３のいずれか１項に記載の同期制御システム。 It has a thread control block that is generated for each thread to control threads.
Any of claims 1 to 3, wherein a wait management queue for managing a group of threads waiting by the same lock object is registered in the thread control block related to the thread that has been put into a waiting state by the lock object. The synchronous control system according to item 1.
異なるプロセッサコアまたは同一のプロセッサコアに割り当てられたスレッド間での同期処理を実行するための共有資源であり、割り当てられた前記プロセッサコアにかかわらずすべてのスレッドがアクセス可能なロックオブジェクトを生成するステップと、
前記ロックオブジェクトによりスレッドが待ち状態となったときに、前記ロックオブジェクトに当該スレッドのスレッド識別子を登録するステップと、
前記ロックオブジェクトにより待ち状態となったスレッドの待ち状態の解除を行うときに、当該ロックオブジェクトを検索して次に起床する待ち状態のスレッドのスレッド識別子を取得し、当該スレッド識別子を使用したメッセージングによりスレッドを実行可能状態に移行させるステップと、
を備える、同期制御方法。 A synchronous control method that runs on a computer with multiple processor cores.
A shared resource for performing synchronous processing between threads assigned to different processor cores or the same processor core, and the step of creating a lock object that is accessible to all threads regardless of the assigned processor core. When,
When a thread is put into a waiting state by the lock object, a step of registering the thread identifier of the thread in the lock object and
When releasing the waiting state of a thread that has been in the waiting state by the lock object, the lock object is searched for, the thread identifier of the waiting thread that wakes up next is acquired, and messaging using the thread identifier is performed. Steps to move a thread to a viable state,
A synchronous control method.
前記ロックオブジェクトによりスレッドが待ち状態となったときに、当該スレッドが実行されているプロセッサコアの番号に対応した前記スレッド情報格納配列の要素に当該スレッドのスレッド識別子を格納する、請求項７記載の同期制御方法。 The lock object includes a thread information storage array which is an array for the number of the plurality of processor cores.
The seventh aspect of claim 7, wherein when the thread is put into a wait state by the lock object, the thread identifier of the thread is stored in the element of the thread information storage array corresponding to the number of the processor core in which the thread is executed. Synchronous control method.
前記ロックオブジェクトによりスレッドが待ち状態となったときに、当該スレッドに係る前記スレッド制御ブロックに、同じロックオブジェクトにより待ち状態となったスレッド群を管理するための待ち管理キューが登録される、請求項７〜９のいずれか１項に記載の同期制御方法。 It has a thread control block that is generated for each thread to control threads.
Claim that when a thread is put into a waiting state by the lock object, a wait management queue for managing a group of threads waiting by the same lock object is registered in the thread control block related to the thread. The synchronous control method according to any one of 7 to 9.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2019183481A JP7054688B2 (en) | 2019-10-04 | 2019-10-04 | Synchronous control system and synchronous control method |
| JP2022062393A JP7346649B2 (en) | 2019-10-04 | 2022-04-04 | Synchronous control system and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2019183481A JP7054688B2 (en) | 2019-10-04 | 2019-10-04 | Synchronous control system and synchronous control method |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2022062393A Division JP7346649B2 (en) | 2019-10-04 | 2022-04-04 | Synchronous control system and method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2021060707A true JP2021060707A (en) | 2021-04-15 |
| JP7054688B2 JP7054688B2 (en) | 2022-04-14 |
Family
ID=75380138
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2019183481A Active JP7054688B2 (en) | 2019-10-04 | 2019-10-04 | Synchronous control system and synchronous control method |
| JP2022062393A Active JP7346649B2 (en) | 2019-10-04 | 2022-04-04 | Synchronous control system and method |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2022062393A Active JP7346649B2 (en) | 2019-10-04 | 2022-04-04 | Synchronous control system and method |
Country Status (1)
| Country | Link |
|---|---|
| JP (2) | JP7054688B2 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7350807B2 (en) | 2021-07-01 | 2023-09-26 | イーソル株式会社 | Message sending/receiving methods and operating systems |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07160645A (en) * | 1993-12-02 | 1995-06-23 | Fujitsu Ltd | Common resource exclusive control method in multiprocessor system |
| JP2011232956A (en) * | 2010-04-27 | 2011-11-17 | Clarion Co Ltd | Computer system and program |
| JP2013168103A (en) * | 2012-02-17 | 2013-08-29 | Nec Computertechno Ltd | Information processor and information processing method |
| JPWO2013175858A1 (en) * | 2012-05-23 | 2016-01-12 | 日本電気株式会社 | Lock management system, lock management method, and lock management program |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1185546A (en) * | 1997-09-12 | 1999-03-30 | Hitachi Ltd | Inter-process communicating method on heterogeneous os |
| JP6094037B2 (en) | 2012-02-24 | 2017-03-15 | カシオ計算機株式会社 | Imaging apparatus, imaging method, and imaging program |
| JP5945617B2 (en) | 2015-04-15 | 2016-07-05 | イーソル株式会社 | Multicore processor control program, electronic device, and control method |
-
2019
- 2019-10-04 JP JP2019183481A patent/JP7054688B2/en active Active
-
2022
- 2022-04-04 JP JP2022062393A patent/JP7346649B2/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07160645A (en) * | 1993-12-02 | 1995-06-23 | Fujitsu Ltd | Common resource exclusive control method in multiprocessor system |
| JP2011232956A (en) * | 2010-04-27 | 2011-11-17 | Clarion Co Ltd | Computer system and program |
| JP2013168103A (en) * | 2012-02-17 | 2013-08-29 | Nec Computertechno Ltd | Information processor and information processing method |
| JPWO2013175858A1 (en) * | 2012-05-23 | 2016-01-12 | 日本電気株式会社 | Lock management system, lock management method, and lock management program |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7350807B2 (en) | 2021-07-01 | 2023-09-26 | イーソル株式会社 | Message sending/receiving methods and operating systems |
Also Published As
| Publication number | Publication date |
|---|---|
| JP7054688B2 (en) | 2022-04-14 |
| JP7346649B2 (en) | 2023-09-19 |
| JP2022079764A (en) | 2022-05-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7373640B1 (en) | Technique for dynamically restricting thread concurrency without rewriting thread code | |
| JP3882931B2 (en) | Management of dispatch function in virtual machine environment | |
| US8161453B2 (en) | Method and apparatus for implementing task management of computer operations | |
| US6732138B1 (en) | Method and system for accessing system resources of a data processing system utilizing a kernel-only thread within a user process | |
| US9063783B2 (en) | Coordinating parallel execution of processes using agents | |
| US20070157200A1 (en) | System and method for generating a lock-free dual queue | |
| US20050240930A1 (en) | Parallel processing computer | |
| US9378069B2 (en) | Lock spin wait operation for multi-threaded applications in a multi-core computing environment | |
| JPH03161859A (en) | Request control method and access control system | |
| KR20040086214A (en) | Enhanced runtime hosting | |
| JP2009265963A (en) | Information processing system and task execution control method | |
| JP2004326753A (en) | Management of lock in virtual computer environment | |
| US10331500B2 (en) | Managing fairness for lock and unlock operations using operation prioritization | |
| US20110265093A1 (en) | Computer System and Program Product | |
| US20170344398A1 (en) | Accelerator control device, accelerator control method, and program storage medium | |
| US7765548B2 (en) | System, method and medium for using and/or providing operating system information to acquire a hybrid user/operating system lock | |
| US10095627B2 (en) | Method and system for efficient communication and command system for deferred operation | |
| US10445096B2 (en) | Managing lock and unlock operations using traffic prioritization | |
| US10360079B2 (en) | Architecture and services supporting reconfigurable synchronization in a multiprocessing system | |
| JP7346649B2 (en) | Synchronous control system and method | |
| US20080134187A1 (en) | Hardware scheduled smp architectures | |
| CN115408117A (en) | Coroutine operation method and device, computer equipment and storage medium | |
| US9201688B2 (en) | Configuration of asynchronous message processing in dataflow networks | |
| US9547522B2 (en) | Method and system for reconfigurable virtual single processor programming model | |
| Rothberg | Interrupt handling in Linux |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20201111 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20210915 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20211012 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20211201 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20220308 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20220404 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 7054688 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |