WO2009113381A1 - マルチプロセッサシステム、マルチプロセッサシステムのｏｓ間デバイス共有方法 - Google Patents

マルチプロセッサシステム、マルチプロセッサシステムのｏｓ間デバイス共有方法 Download PDF

Info

Publication number
WO2009113381A1
WO2009113381A1 PCT/JP2009/053236 JP2009053236W WO2009113381A1 WO 2009113381 A1 WO2009113381 A1 WO 2009113381A1 JP 2009053236 W JP2009053236 W JP 2009053236W WO 2009113381 A1 WO2009113381 A1 WO 2009113381A1
Authority
WO
WIPO (PCT)
Prior art keywords
interface unit
task
request
processing
device driver
Prior art date
Application number
PCT/JP2009/053236
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 US12/919,636 priority Critical patent/US8661458B2/en
Priority to JP2010502756A priority patent/JP5516398B2/ja
Publication of WO2009113381A1 publication Critical patent/WO2009113381A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space

Definitions

  • the present invention relates to a multiprocessor system in which a plurality of OSs operate, and more particularly to a multiprocessor system in which devices are shared among a plurality of OSs, and a method of sharing devices between OSs.
  • OSs of the same or different types are useful as a means for improving the reliability and responsiveness of the entire system.
  • peripheral devices such as DMA controllers, graphic accelerators, multimedia dedicated engines, HDD (hard disk) controllers, etc. among multiple OSs on multi-core processors.
  • DMA controllers graphic accelerators
  • HDD controllers hard disk controllers
  • device management is normally closed within the OS as the role of the OS, and it is not assumed that devices under the management of one OS will be accessed by another OS.
  • Non-Patent Document 1 As a method of sharing and using a device among a plurality of OSs, there is a client-server method as described in Non-Patent Document 1 and Non-Patent Document 2.
  • This client-server method limits the number of OSs accessing a device to one, and then runs a server task called an access server on that OS, and the other tasks on the OS are access servers by inter-OS communication It is a method to communicate with the system and make the access server substitute for the access of the device.
  • This access server is sometimes called a proxy because it plays the role of proxying device access.
  • Non-Patent Document 1 and Non-Patent Document 2 have the following problems.
  • the first problem is that the device access performance through the server is degraded because it is necessary to switch tasks to the proxy or access server each time a device access request to the server is required. This is a serious problem especially in devices where speed is important, such as graphic accelerators and HDDs.
  • the second problem is that it is necessary to implement a proxy function for each type of device access in the access server, and the development cost is high.
  • APIs application program interfaces
  • An object of the present invention is to provide a multiprocessor system capable of sharing OS devices with reduced degradation of device access performance, and a method of sharing OS devices of a multiprocessor system.
  • Another object of the present invention is to provide a multiprocessor system that can reduce the development cost required for inter-OS device sharing, and an inter-OS device sharing method of the multiprocessor system.
  • the plurality of OSs have a device driver for accessing a device shared among the OSs, and the device driver is an OS between OSs in the OS kernel layer
  • the device interface unit has at least one of a device interface unit and a task interface unit to communicate, the device interface unit accesses a device to be operated by the device driver, and the task interface unit is a device from a task on each OS Accept access request and return device access result to task.
  • a device driver is a device driver included in an OS for accessing a device shared among the OSs of a multiprocessor system in which a plurality of OSs operate, and a device interface unit for accessing a device to be manipulated by the device driver. And a task interface unit that performs inter-OS communication in the device interface unit and the OS kernel layer, receives a device access request from a task on each OS, and returns the device access result to the task.
  • the inter-OS device sharing method is an inter-OS device sharing method of a multiprocessor system in which a plurality of OSs having a device driver for accessing a device shared among the OS operate, the device driver comprising a device interface unit And at least one of the task interface units, the task interface unit and the device interface unit perform inter-OS communication in the OS kernel layer, and the device interface unit accesses the device driver operation target device, and the task
  • the interface unit accepts device access requests from tasks on each OS and returns device access results to the tasks.
  • a first effect of the present invention is to improve the device access performance from client-side tasks by the client-server method.
  • the second effect of the present invention is that the software development cost for device sharing can be reduced.
  • FIG. 1 is a block diagram showing an overall configuration of a system according to a first embodiment of the present invention.
  • FIG. 7 is a diagram showing an internal configuration of device drivers on OS-A and OS-B in the first embodiment of the present invention. It is a figure which shows the internal structure of the process request
  • FIG. 7 is a block diagram showing an internal configuration of a device driver communication unit on OS-A and OS-B in the first embodiment of the present invention. It is a figure which shows the internal structure of the call request
  • 7 is a flowchart showing an initial setting procedure of an OS-A device driver in the first embodiment of the present invention.
  • 7 is a flowchart showing an initial setting procedure of the device driver for OS-B in the first embodiment of the present invention. It is a flowchart which shows operation
  • 6 is a flowchart showing an operation of a device setting unit of the device driver for OS-A in the first embodiment of the present invention. It is a flowchart which shows operation
  • FIG. 16 is a diagram showing an internal configuration of device drivers on OS-A and OS-B according to a fourth embodiment of the present invention.
  • the shared memory multiprocessor system having a plurality of OSs includes a multi-core processor 10 and two types of OSs, OS-A40 and OS-B50. , And user tasks 43 and 53 on each OS, and a memory 31 connected to the external bus 30 of the multi-core processor 10.
  • the multi-core processor 10 has two CPU cores, ie, a CPU core (0) 20 and a CPU core (1) 21, an interrupt control unit 12, an inter-core interrupt generation unit 13 that generates an interrupt among CPU cores among interrupts, and an OS And an internal device 14 shared by the plurality of processors, which are connected by a processor internal bus 11.
  • OS-A 40 is running on the CPU core (0) 20.
  • the OS-A 40 incorporates a device driver 41 for accessing the internal device 14, and a user task (A0) 43 for accessing the internal device 14 exists on the OS.
  • the OS-A 40 has a device driver communication section (A) 42 for communicating with another adjacent OS.
  • OS-B 50 is operating on the CPU core (1) 21.
  • the OS-B 50 incorporates a device driver 51 for accessing the internal device 14, and a user task (B0) 53 for accessing the internal device 14 exists on the OS.
  • the OS-B 50 has a device driver communication unit (B) 52 for communicating with another adjacent OS.
  • B device driver communication unit
  • the present invention is limited to the multi-core processor of the two-core configuration
  • the present invention is applicable to any configuration including a plurality of CPU cores, and is also applicable to a configuration in which three or more types of OS operate.
  • the internal device 14 and the external device 32 are respectively connected on the internal bus 11 of the multicore processor 10 and the external bus 30, the number of the devices and the internal / external distinction of connection destinations Does not preclude the application of the present invention. Furthermore, even if the interrupt control unit 12 or the inter-core interrupt generation unit 13 is connected to the external bus 30 of the multi-core processor 10, the present invention can be applied as it is.
  • the OS-A device driver 41 incorporated in the OS-A 40 receives a request from the user task (A) 43 and returns a processing result to the user task (A) 43.
  • the device interface unit (A) 45 which controls the operation of the unit (A) 44 and the internal device 14 or observes the state thereof and receives the result from the device and the task interface unit (A) 44 received from the user task
  • processing is a request waiting list 46 which is an area for storing processing requests for which processing has not been started by an internal device which is a target device yet, and a process for storing processing information currently being executed by a target device.
  • a middle list 47 is provided.
  • the task interface unit (A) 44 internally has a request interpretation unit (A) 441 for receiving a processing request from the user task (A) 43 and a user task (A) 43 with control of the operation of the user task. And a standby task resumption unit (A) 442 for returning.
  • the device interface unit (A) 45 internally sets values in registers of the internal device 14 and the like, and a device setting unit 451 that handles communication interrupts from device drivers on other OSs, and from the internal device 14 And a device interrupt processing unit 452 that handles interrupts.
  • the OS-A 40 internally includes, in addition to the OS-A device driver 41, a device driver communication unit (A) 42 for communicating with device drivers on other OSs. Further, on the OS-A 40, a user task (A0) 43 that issues an access request to the internal device 14 is operating.
  • the internal device 14 is connected to an interrupt control unit 12 that generates an interrupt to the CPU core in order to notify the OS side of a state change such as completion of a given process.
  • the OS-B 50 is similar to the internal structure of the OS-A 40 except that it does not have the device interface unit (A) 45 and the data structure (request waiting list 46, in-process list 47) associated therewith. .
  • the internal configuration of the OS-B will be described with reference to FIG.
  • the OS-B device driver 51 incorporated in the OS-B 50 receives the request from the user task (B) 53, and returns the processing result to the user task (B) 53.
  • the task interface unit (B) 54 Equipped with The OS-B 50 also includes an inter-device driver communication unit (B) 52 for performing communication between the OS-B device driver 51 and the OS-A device driver 41.
  • the task interface unit (B) 54 internally has a request interpretation unit (B) 541 for receiving a processing request from the user task (B) 53, and controls the operation of the user task and returns the processing result to the user task. And a standby task resumption unit (B) 542 of
  • the device driver is configured with a task interface unit and a device interface unit, both are mounted on the OS (OS-A40) that directly accesses the device, and the other OS (OS-B50)
  • OS OS-A40
  • OS-B50 OS-B50
  • the request waiting list 46 and the processing-in-progress list 47 are configured as a processing request structure 70 shown in FIG. 3 as a data element, and these are connected by a list.
  • An instance of the process request structure 70 is created by the request interpreter of the task interface unit of the device driver on each OS, and linked to the request waiting list 46.
  • the instance of the process request structure 70 is removed from the request waiting list 46 and moved to the in-process list 47.
  • the standby task resumption unit of the task interface unit of the device driver on each OS removes the instance of the processing request structure in the processing list 47 and returns the processing result to the calling user task.
  • the request waiting list 46 and the in-process list 47 may be implemented as first-in first-out, or FIFO.
  • the processing request structure 70 has the following fields in its interior.
  • the processing request identifier 71 is an identifier for uniquely identifying an instance of the processing request structure 70.
  • the request source OS identifier 72 is an identifier for identifying the OS under which the user task that has requested the process has been executed, and in the example of FIG. 2, is an identifier pointing to the OS-A 40 or the OS-B 50.
  • the request source task identifier 73 is an identifier for uniquely identifying the user task that has requested the process in the OS that has run the user task, and for example, the task ID itself managed by each OS is used. .
  • the device setting information 74 holds information on values to be set for the target internal device by the device driver in accordance with the request from the user task.
  • the device setting information 74 is, for example, a transfer source address, a transfer destination address, and a transfer size if the device driver is a DMA controller, and a 3D drawing command sequence if the device driver is a graphic accelerator.
  • the device setting information 74 since the content held by the device setting information 74 largely varies depending on the device, in the processing request identifier 71 for a specific device, the device setting information 74 always has the same size. This facilitates memory management of the instance of the process request structure 70.
  • the area of the device setting information 74 has a size that can hold data of the maximum size actually assumed as the device setting information, and if necessary, the processing request content is divided and expressed into a plurality of processing request identifiers. This division is performed by the task interface units 44 and 54.
  • the device state 75 is a field for storing the result of processing the user request by the internal device.
  • the content stored in the device status 75 is, for example, in the case of a DMA controller or a graphic accelerator, a simple integer value indicating whether or not the request processing has succeeded, but in the case of an HDD controller, it is read from the HDD Like data strings, they can be large sized data.
  • the device status 75 must be immediately removed from the device after the completion interrupt from the device has been transmitted to the OS side because it is overwritten by the subsequent device processing or the start of the subsequent device processing is prevented. Design to hold only the data that you must have. Also, the size of this device state 75 is designed to be always the same size for a specific device. This is to facilitate memory management as in the case of the device setting information 74.
  • the configuration of the communication unit between device drivers which plays an important role in improving the device access performance in the present embodiment, will be described with reference to FIG. Note that although there is one device driver communication unit in each OS, all have the same configuration.
  • the device driver communication unit (A) 42 on the OS-A 40 side will be described below, but the device driver communication unit (B) 52 on the OS-B 50 side has the same configuration.
  • the communication between device drivers in this embodiment communicates in a concept similar to remote procedure call (RPC) in that another OS side calls a routine registered on one OS side in advance.
  • RPC remote procedure call
  • the communication between device drivers in the present embodiment is characterized in that most part is performed in the interrupt handler, which brings about an effect of reducing communication overhead.
  • the device driver communication section (A) 42 on the OS-A 40 side holds a registered routine on the OS-A 40 side in association with the prior routine registration, and the called routine registration table (A) 422 and its table A called routine registration unit (A) 421 is provided to register a routine in advance.
  • the device driver communication unit (A) 42 also manages a list of unexecuted call requests for registered routines on the OS-A side in a list in relation to management of the status called from the other OS side ((A)) A) 423 and a called state storage unit (A) 424 indicating whether the inter-device driver communication unit (A) 42 is currently calling any of registered routines.
  • the device driver communication unit (A) 42 also includes the following two processing units in connection with the operation of calling the other party or being called by the other party.
  • an inter-core interrupt is generated by a call processing unit (A) 426 that generates an inter-core interrupt and calls a device driver communication unit on another OS. It is a called processing unit (A) 425 that performs registered routine calling processing in response to a request from another OS via the received OS.
  • the called processing unit (A) 425 be directly called from the interrupt receiving unit 48 of the OS-A 40 as processing in the interrupt handler in order to speed up communication.
  • the processing of the callee processing unit (A) 425 is implemented as a kernel task, that is, a task or thread operating in the OS kernel.
  • the interrupt acceptance unit 48 of -A 40 may be configured to perform only the activation of the kernel task.
  • the call request list (A) 423 stores an instance of the call request structure 80 shown in FIG.
  • the call request structure 80 includes three fields of a request source OS identifier 81, a call routine identifier 82, and a call parameter 83.
  • the request source OS identifier 81 is an identifier for identifying the OS on which the device driver that has requested the process has been executed, and in the example of FIG. 2, is an identifier pointing to the OS-B 50.
  • the request source OS identifier 81 can not be a value other than the OS-B 50, but three or more OSs operate.
  • the request source OS identifier 81 can take a plurality of values.
  • the calling routine identifier 82 designates one of the routines registered in the called routine registration table 422.
  • the call parameter 83 is an area for storing parameters (arguments) at the time of executing the called routine.
  • the parameter group is generally different for each calling routine, but it is desirable to make the field of the calling parameter 83 a small fixed size by designing the calling routine so as to require as few and small sized parameters as possible. This is to facilitate memory management as in the case of the device setting information 74.
  • the call request list (A) 423 is a list structure in which an instance of the call request structure 80 is stored in a FIFO manner, as shown in FIG.
  • the call request structure 80 is in the order of the call request structure (1) 80-1, the call request structure (2) 80-2, the call request structure (3) 80-3, and so on. It is stored and taken out in the order of call request structure (1) 80-1, call request structure (2) 80-2, and call request structure (3) 80-3.
  • Initial setting is performed for each of the device driver communication units (A) 42 and (B) 52, the device driver 41 for OS-A, and the device driver 51 for OS-B.
  • the initial setting of the device driver communication unit (A) 42 is performed in step 206 of registering the called processing unit (A) 425 as an inter-frame interrupt handler of the OS, and the called state storage unit (A). It comprises step 207 of turning off (clearing) the in-process flag 424.
  • the device driver communication unit (B) 52 also comprises a step of registering the called processing unit (B) 525 as an inter-frame interrupt handler of the OS and a step of clearing the called state (B) 524.
  • the initialization of the OS-A device driver 41 is performed in the following three steps.
  • step 201 the device completion interrupt process routine in the device interrupt processing unit 452 of FIG. 2 is registered as an interrupt handler from the internal device 14. This process is executed using the function of OS-A40.
  • step 202 a device setting routine, which will be described later, is registered as one of the called routines for the communication between device drivers in the OS-A 40.
  • This registration is executed by calling the called routine registration unit (A) 421 (FIG. 4) of the device driver communication unit (A) 42.
  • step 203 both the request waiting list 46 and the in-process list 47 in the OS-A device driver 41 are emptied.
  • the initial setting of the OS-B device driver 51 includes the following steps. That is, in step 211, a task resume B routine described later is registered as one of the called routines of the communication between device drivers in the OS-B 50. This registration is executed by calling the called routine registration unit (B) 521 (FIG. 4) of the device driver communication unit (B) 52.
  • the task interface unit (A) 44 on the OS-A 40 side will be described.
  • the task interface unit (A) 44 includes the request interpretation unit (A) 441 and the standby task resumption unit (A) 442.
  • the request interpreter (A) 441 When there is a device access request from the user task 43, the request interpreter (A) 441 is called first. The flow of processing in the request interpretation unit (A) 441 is shown in FIG.
  • the request interpreter (A) 441 first creates a new instance of the process request structure 70 at step 221.
  • the structure of the processing requirement structure 70 is as shown in FIG.
  • the processing request identifier field 71 is set to a unique integer value in this device driver, and the request source OS identifier field 72 is a value indicating OS-A.
  • the request source task identifier field 73 the task ID of the user task 43 that has made the device access request this time is set.
  • the device setting information field 74 stores information such as the type of the device access request of this time, parameters, and the like for specifying an operation performed by the device interface unit (A) 45 of the device driver on the internal device 14. . None is set in the device status field 75 at this time.
  • the request interpreter (A) 441 registers the process request structure instance created above in the request waiting list 46 in the device driver for OS-A.
  • the request waiting list 46 is accessed by the task interface unit (A) 44 of the OS-A, the task interface unit (B) 54 of the OS-B, and the device interrupt processing unit 452 of the OS-A.
  • the interrupt is prohibited, and then the actual registration operation (step 224) is performed in the section protected by the exclusive control, that is, the lock-unlock operation.
  • the lock-unlock operation is performed, for example, using an instruction sequence combining an exclusive control service function provided by the OS or an exclusive control instruction possessed by the CPU.
  • the lock operation is performed in a busy wait type, that is, in the case where the lock is already in progress, the lock is repeatedly attempted until the lock can be secured.
  • the reason why the lock is performed in the busy wait type is that the exclusive control section is short in this embodiment, so it is expected that the exclusive control section is immediately exited even if others are executing in the exclusive control section. It is.
  • step 223 may be timed out, and the entire processing request of FIG. 9 may end with an error. It is.
  • the request interpretation unit (A) 441 calls a device setting routine, which is processing stored in the device setting unit 451 in the same device driver.
  • the operation of this device setting routine will be described later, but the outline is processing of taking out the next processing request structure from the request waiting list 46 and setting the internal device 14 appropriately.
  • the request interpretation unit (A) 441 permits the interrupt in step 227, and causes the user task (A0) 43 to transition to the wait state (sleep state) in step 228 using the service function of OS-A.
  • the OS-A suspends the execution of the caller user task (A0) 43, and if there is another executable user task, it switches the task to that task.
  • the above is the flow of the operation of the request interpretation unit (A) 441.
  • the device interrupt processing unit 452 stores the processing result in the device status field 75 of the processing request structure 70, and the standby task resumption unit (A) 442 of the task interface unit (A) 44. Call. Although this series of processing will be described later, here, the flow of the operation of the standby task resumption unit (A) 442 will be described using FIG.
  • the device processing result is read from the device status field 75 of the processing request structure 70, and the device processing result is copied to a predetermined memory area in the calling user task (A0) 43.
  • this copy is performed by calling an OS-provided service function that executes copying from the kernel space to the user task space.
  • step 232 the memory of the processing request structure 70 secured at step 221 described above is released, and finally at step 233, the user task (A0) 43 can be executed using the service function of OS-A 40. Transition to
  • the OS-A 40 resumes the execution of the user task (A0) 43 suspended while waiting for device processing.
  • the above is the flow of the operation of the standby task resumption unit (A) 442.
  • the task interface unit (B) 54 on the OS-B 50 side will be described.
  • the task interface unit (B) 54 includes the request interpretation unit (B) 541 and the waiting task resumption unit (B) 542. They perform operations similar to the corresponding parts on the OS-A 40 side, except that they act on the OS-A side regarding the request wait list, the in-process list, and the interaction with the device interface unit.
  • the request interpretation unit (B) 541 When there is a device access request from the user task (B0) 53 on the OS-B 50, the request interpretation unit (B) 541 is first called. The flow of processing in the request interpretation unit (B) 541 is shown in FIG.
  • the request interpretation unit (B) 541 first creates a new instance of the process request structure 70 at step 241. This step is similar to step 221 which is the corresponding processing on the OS-A 40 side, but in the request source OS identifier field 72, a value for identifying the OS-B 50 is set.
  • the request interpreter (B) 541 registers the instance of the processing request structure 70 created above in the request waiting list 46 in the device driver 41 for OS-A. As shown in steps 242 and 244 of FIG. 11, an actual registration operation (step 243) is performed within the section protected by the lock-unlock operation for the inter-OS exclusive control.
  • lock and unlock operations are performed using an instruction sequence combining an exclusive control service function provided by the OS or an exclusive control instruction possessed by the CPU.
  • the request interpretation unit (B) 541 designates the following parameters and calls the device driver communication unit (B) 52, whereby the device interface unit (A) on the OS-A side Call setup routine remotely.
  • call destination OS OS-A
  • call routine identifier identifier of device setting routine (registered at step 202)
  • call parameter none
  • the request interpretation unit (B) 541 causes the user task (B0) 53 to transition to the waiting state (sleep state) using the service function of the OS-B 50 at step 246.
  • the OS-B 50 suspends the execution of the caller user task (B0) 53, and if there is another executable user task, it switches the task to that task.
  • the above is the flow of the operation of the request interpretation unit (B) 541.
  • step 251 the device processing result is read from the device status field 75 of the processing request structure 70 given as an argument, and the device processing result is copied to a predetermined memory area in the calling user task (B0) 53.
  • this copy is performed by calling an OS-provided service function that executes copying from the kernel space to the user task space.
  • step 252 the memory of the processing request structure 70 secured in step 241 is released, and finally in step 253, the user task (B0) 53 is made executable using the service function of OS-B 50. Make a transition.
  • the OS-B 50 resumes the execution of the user task (B0) 53 suspended while waiting for device processing.
  • the above is the description of the operation of the task interface unit of each device driver.
  • the device interface unit (A) 45 includes the device setting unit 451 and the device interrupt processing unit 452.
  • the flow of the operation of the device setting unit 451 will be described with reference to FIG.
  • the device setting unit 451 is assumed to be called in the interrupt disabled state.
  • steps 261 to 263 the continuation condition of the loop process of device setting is determined. If there is no processing request structure in the request waiting list 46, or if the number of repetitions of the loop continuation exceeds the predetermined upper limit, or the internal device 14 is already processing, new processing is accepted If not, the loop is exited and the device setting process is terminated.
  • the upper limit value of the loop continuation is set in order to prevent an adverse effect on other processing (for example, task switching of the OS or real time processing) by prolonging the interrupt disabled section by repeating the device setting.
  • the loop continuation upper limit value is set to n or less. On the other hand, if the internal device can accept at most one processing request, the loop continuation upper limit value is fixed to one.
  • an embodiment using the upper limit value of the time spent for the present device setting process in place of the loop continuation upper limit value can be considered.
  • the current time is acquired by the timer or the like at the start of the device setting process, the current time is acquired again by the timer or the like in step 262, and the elapsed time from the start time is calculated. Then, the flow of operation ends the device setting.
  • one processing request structure instance is fetched from the request waiting list. Instances to be extracted are selected according to a predetermined rule from all the instances stored in the request waiting list. For example, a rule is used that first arrives first in time (FIFO).
  • the lock-unlock operation for exclusive control is held back and forth.
  • This lock-unlock is realized by a combination of exclusive control service function calls by the OS or exclusive control instructions possessed by the CPU.
  • This lock operation is performed in the busy wait type, that is, in the case where the lock is already performed, it is repeated until the lock can be secured.
  • step 267 with reference to the device setting information field 74 of the processing request structure 70, the setting value is written to the internal device 14, and the internal device 14 is transitioned to the target operating state.
  • this step 267 is mounted differently for each target device, for example, in the case of a DMA controller, the setting values are written to the transfer source address register, transfer destination address register, and transfer size register, and predetermined bits of the control register are set. And start the DMA transfer. Further, taking the graphic accelerator as another example, the drawing command sequence is created on the work memory according to the contents of the device setting information field 74, and the drawing process of the graphic accelerator is started by setting a predetermined bit of the control register. And so on. These processes are similar to processes performed by related art device drivers such as general DMA device drivers and graphic accelerator device drivers for respective internal devices.
  • the value of the identifier for identifying the plurality of processes input to the device is the processing request identifier of the processing request structure 70 Set in field 71.
  • this identifier differs depending on the device, it is, for example, a transaction ID or a command queuing ID.
  • step 268 an instance of the process request structure 70 extracted at step 265 described above is registered in the in-process list 47.
  • the in-process list 47 is also accessed from the task interface unit (A) 44 of the OS-A, but the task interface unit (A) 44 and the device interface unit 45 have already performed exclusive control by the interrupt disable / enable operation. Therefore, special exclusion control processing is not necessary before and after step 268.
  • the device interrupt processing unit 452 is called from the internal device as a handler for an interrupt to the OS-A 40, so that the entire process is executed in the interrupt disabled state.
  • the device status is read from the internal device 14 promptly. This is to prevent the device state from changing due to the next external event to the device, such as completion of the subsequent graphic drawing process or completion of the subsequent disk read process, or by the device such as a serial port or the like. The reason is that the next device processing may not proceed unless the device status is read, and the situation may be avoided.
  • an instance of the process request structure 70 corresponding to the current completion interrupt is fetched from the in-process list 47.
  • the internal device 14 is a device of a type that accepts a plurality of processing requests
  • the value of the processing request identifier field 71 set in the above-mentioned step 267 is collated with the internal device side, and the corresponding instance of the processing request structure 70 Uniquely identify
  • the device state value read at step 271 is stored in the device state field 75 of the processing request structure 70 retrieved at step 272.
  • the state after completion of processing of the internal device can be saved in the instance of the processing request structure 70.
  • the requestor OS is determined with reference to the requestor OS identifier 72 of the processing request structure instance.
  • step 275 the standby task restart unit (A) 442 is called with the instance of the process request structure 70 as an argument.
  • the flow of processing in the standby task resumption unit A is as described in step 231 to step 233 in FIG. By this operation, the operation of the caller user task (A0) 43 on the OS-A 40 waiting for the device processing completion is resumed.
  • the request source OS is other than OS-A, at step 277, the following parameters are designated to call the device driver communication section (A) 42, thereby waiting tasks of the device interface section of the request source OS. Remotely call the resumption unit.
  • Call destination OS request source OS
  • call routine identifier identifier of task restart routine of request source OS (registered at step 211)
  • call parameter processing request structure instance
  • step 276 the device setting routine in the device setting unit 451 is called, and the next processing is set to the internal device 14.
  • the operation of this portion is as described in step 261 to step 268 of FIG.
  • inter-device driver communication unit (A) 42, (B) 52 which directly communicates between device drivers on different OSs.
  • One set of communication is unidirectional communication from one device driver to the other device driver, and two sets of the same type can realize two-way communication. Therefore, the operation of one set of unidirectional communication will be described below.
  • the device driver communication unit (A) 42, (B) 52 is a parameter for remote call, that is, the OS of the communication partner, the call routine identifier to be called on the OS, and the call parameter to be passed to the routine. It is called from the device driver of each OS by specifying three.
  • step 281 device-driver communication sections (A) 42 and (B) 52 are shown in FIG. 5 using two of the call routine identifier and the call parameter among the given parameters.
  • the request source OS identifier field 81 a value for identifying the OS of the caller is set.
  • step 283 the instance of the call request structure 80 is added to the call request list (A) 423 or (B) 523 of the call destination OS. Since this call request list is also accessed by the other OS, the lock is acquired in the immediately preceding step 282 for exclusive control. This lock is performed by an exclusive control instruction provided by the CPU itself or an equivalent OS service function.
  • step 284 it is determined whether the device driver communication unit of the other OS is in process. This is determined by directly referring to the in-processing flag of the called state storage unit (424 to 524 in FIG. 4) in the device driver communication unit of the other party.
  • an inter core interrupt to the other OS is generated. This is performed by requesting the inter-core interrupt generation unit 13 to perform an inter-CPU core interrupt to the CPU core on which the other OS operates, using a hardware operation instruction of the CPU itself or an OS service function corresponding thereto. As a result, the device driver communication section of the other party starts processing the new request stored in the call request list 523 or 523. This will be explained shortly.
  • step 283 If the other party's device driver communication section is processing, the request added to the call request list 423 or 523 in step 283 will be processed in a short time, so the step 285 is simply skipped and the next step is advanced.
  • step 286 the lock acquired at step 282 is unlocked, and the exclusive control section is exited.
  • the called processing units 425 and 525 examine the call request lists 423 and 523 of the own OS in step 292, and if it is empty, in step 297, the called state storage unit (424 to 524 in FIG. 4) The processing-in-progress flag is turned off (processing is not in progress), and the entire processing of the called processing units 425 and 525 is completed.
  • call request lists 423 and 523 are not empty, one instance of the call request structure 80 is taken out from the top of the call request list 423 or 523 in step 293, and in step 294 the called state storage unit (FIG. After setting the processing-in-progress flag on (processing-in), the pre-registered routine is called in step 296.
  • step 292 to step 294 and step 297 are protected by lock-unlock exclusive control.
  • This lock is performed by an exclusive control instruction provided by the CPU itself or an equivalent OS service function.
  • the call is called by searching the callee routine registration table (422 to 522 in FIG. 4) in the own OS using the call routine identifier field 82 of the call request structure 80 as a key. Identify the routine to be done. Then, the called routine is called with the value stored in the calling parameter field 83 of the calling request structure 80 as an argument of the routine.
  • FIG. 18 shows that two tasks being executed on the OS-A 40, that is, a user task (A0) and a user task (A1) share access to a certain device.
  • time flows downward from the top and the elongated rectangle in the vertical direction indicates the portion in which the task or component operates, and the rectangle with the elongated hatching in the vertical direction indicates data in the component Indicates that an (instance) exists.
  • the solid arrows in the horizontal direction indicate the call or interrupt of the routine, and the dotted arrows indicate the return from those processes.
  • the user task (A0) requests the process “XXX” from the device.
  • the processing request reaches the device setting unit 451 directly from the task interface unit (A) 44 of the OS-A 40, and the device setting unit 451 sets the internal device 14 to start the processing of “XXX”. If the process "YYY” is requested from another user task (A1) before the "XXX” process is completed, the request reaches the device setting unit 451, but the internal device 14 is in the process of "XXX” Therefore, the processing request structure 70 remains in the request waiting list 46. In either case, the user task (A0) and the user task (A1) that are the callers are put on standby in the OS-A 40.
  • the device interrupt processing unit 452 stores the “XXX” processing result of the internal device 14 in the processing list 47 and then calls the standby task resumption unit (A) 442 of the OS-A task interface unit (A) 44.
  • the standby task resumption unit (A) 442 reads out the processing list 47, acquires the processing result, and resumes the user task A0 in the waiting state.
  • the device interrupt processing unit 452 further calls the device setting unit 451, takes out the next process "YYY" waiting in the request waiting list 46, and sets it in the internal device 14.
  • the completion interrupt is input to the OS-A 40 as above, and the device interrupt processing unit 452 temporarily stores the processing result in the processing in progress list 47, and then the task interface unit (A)
  • a case will be described in which a device access request is issued from an OS different from the OS that performs device operation.
  • a case where two tasks on the OS-B 50, that is, a user task (B0) and a user task (B1) access a device via the OS-A 40 side will be described as an example.
  • the user task (B0) and the user task (B1) issue device access requests “XXX” and “YYY” one after another. These requests are received by the task interface unit (B) 54 on the OS-B 50 side, and then sent to the device setting unit 451 on the OS-A 40 side via the device driver communication unit (B) 52 and (A) 42.
  • the inter-CPU interrupt by the inter-core interrupt generation unit 13 is used in the device driver communication unit (B) 52 and (A) 42, and the device setting unit 451 is called from the interrupt handler on the OS-A 40 side. It is done.
  • the part where the device setting unit 451 makes settings for the internal device 14 is the same as in the case of FIG.
  • the interrupt between CPU cores by the inter-core interrupt generation unit 13 is used inside the device driver communication (A) 42 and (B) 52, and the wait task restart unit (B) starts from the interrupt handler on the OS-B 50 side. 542 has been called.
  • the part where the standby task resumption part (B) 542 of the task interface part B resumes the user task is the same as that in the case of FIG.
  • the device access performance from the task on the OS-B 50 on the client side can be improved.
  • the reason is that by using high-speed communication means between device drivers in communication between OSs and directly accessing data structures in device drivers between both device drivers, data exchange through communication is reduced. It is because
  • the software development cost for device sharing can be kept low.
  • the reason is that in order to support inter-OS communication (client-server) by using the method of communicating between device drivers that are at the lowest level in the software layer and that implement only a few basic functions. This is because the function requiring modification is minimized.
  • kernel level communication using device driver communication is used in the exchange between the server and the client (OS-A 40 and OS-B 50) without using a separate proxy task.
  • the device driver 51 of the OS-B 50 client side
  • the second embodiment is characterized in that a determination unit 453 is newly provided in the device interface unit (A) 45.
  • the other parts are the same as those of the first embodiment described above.
  • the determination unit 453 has a function of determining acceptance / rejection of one or more instances of the processing request structure 70 stored in the request waiting list 46 according to a certain rule, or processing according to a certain rule next It has a function to select the instance to be.
  • the device setting unit 451 receives an instance of the process request structure 70 determined to be accepted by the determination unit 453 or an instance of the process request structure 70 selected to be processed next.
  • the determining unit 453 discards instances requested by an OS other than the OS (for example, OS-A 40) specified in advance. Or, it is possible to discard an instance requested from a previously specified set of OS-tasks (eg, task # 2 on OS-B 50 and task # 4 on OS-B 50, etc.) is there.
  • the determining unit 453 determines the request source OS value different from the request source OS of the instance selected at the previous determination. Choose an instance with priority, or make sure to select an instance that requires an OS-task pair specified in advance (for example, task # 3 on OS-B) as a request source. Is possible.
  • the third embodiment is characterized in that the request waiting list 46 in the OS-A 40 is composed of a plurality of lists for different purposes.
  • the other parts are the same as in the first embodiment.
  • the third embodiment is characterized in that each list in the request waiting list 46 is associated with each OS.
  • the list 461 corresponds to the OS-A 40
  • the list 462 corresponds to the OS-B 50.
  • the list 463 is not used because only two types of OS are shown.
  • the request interpretation unit (441 and 541 in FIG. 21) of each OS inserts an instance of the processing request structure 70 into the list corresponding to each OS.
  • the device setting unit 451 looks at a predetermined rule, for example, each list in order, extracts an instance of the process request structure 70, and processes.
  • the task interface unit and the device interface unit perform lock / unlock operations for exclusive control for each of the lists 461 to 463 in the request waiting list 46.
  • the third embodiment since lock-unlock of the request waiting list is performed for each OS, a collision occurs at the time of acquiring the lock and the wait is made in comparison with the first embodiment of the present invention. Less likely. That is, the effect of reducing the performance overhead when performing device access can be obtained. This effect is particularly remarkable when making a fine access request to an internal device frequently.
  • each list inside the request waiting list 46 can be configured to be associated with different processing priorities.
  • the list 461 of the request waiting list 46 is associated with the highest priority
  • the list 462 is associated with the normal priority
  • the list 463 is associated with the lowest priority.
  • the device setting unit 451 can refer to the list 462 once, and take control such that the instance of the processing request structure 70 first found is extracted and processed.
  • the device setting unit 451 refers to the list 463 only when the lists 461 and 462 are both empty.
  • the device setting unit 451 can perform access priority control to the internal device by referring to the lists 461 to 463 according to a simple rule based on the number of references. That is, there is obtained an effect that access priority control for internal devices can be realized easily and with low CPU overhead.
  • the determination unit 453 checks the request source task and performs request acceptance / rejection determination, thereby suppressing the performance overhead.
  • An inter-OS device sharing mechanism equipped with an access control function for each task can be constructed.
  • the fourth embodiment is characterized in that the OS-A 40 does not have a task interface unit, but has only a device interface unit.
  • the other parts are the same as in the first embodiment.
  • the OS-A 40 does not operate any user task for accessing the internal device, and the OS-A 40 concentrates on control and management of the internal device.
  • the present embodiment brings about an effect that real-time control of internal devices is easy to perform. This effect is particularly remarkable when using an OS suitable for real-time processing (real-time processing) as the OS-A 40, for example, a real-time OS such as T-Kernel.
  • OS-A40 if using an OS with advanced functions for applications such as UNIX and Windows as OS-B50, it is for real-time performance and application for device control. It is also possible to realize an effect that a system that is compatible with a wealth of functions can be realized on one multi-core processor.
  • the present invention is applicable to a product field where it is necessary to simultaneously satisfy various operation requirements by operating a plurality of OSs on a multi-core processor.
  • a mobile terminal device that performs wireless network processing and application processing for users, an information home appliance that performs broadcast reception, video media processing, and user interface processing, and an on-vehicle device that has powertrain, body, and information media processing combined
  • an on-vehicle device that has powertrain, body, and information media processing combined
  • robot-equipped devices that perform mechatronics control, intelligence processing, and interpersonal interface processing is assumed.

Abstract

　マルチコアプロセッサ上で複数ＯＳを搭載するシステムにおいて、デバイスを複数のＯＳ上のタスクからアクセスする場合、１つのＯＳがデバイスアクセスを代行するクライアント－サーバ方式では、プロキシサーバを置くために性能低下と設計製造コスト上昇という課題があった。 　複数のＯＳ４０、５０が動作するマルチプロセッサシステムにおいて、複数のＯＳが、ＯＳ間で共有するデバイスにアクセスするデバイスドライバ４１、５１を有し、デバイスドライバが、ＯＳカーネル層でのＯＳ間通信を行う、デバイスインタフェース部４５と、タスクインタフェース部４４、５４の少なくとも一方を有し、デバイスインタフェース部４５が、デバイスドライバの操作対象のデバイス１４とのアクセスを行い、タスクインタフェース部が、各ＯＳ上のタスクからのデバイスアクセス要求の受理とデバイスアクセス結果のタスクへの返却を行う。  

Description

マルチプロセッサシステム、マルチプロセッサシステムのＯＳ間デバイス共有方法
　本発明は、複数のＯＳが動作するマルチプロセッサシステムに関し、特に、デバイスを複数ＯＳ間で共有して利用するマルチプロセッサシステム、ＯＳ間デバイス共有方法に関する。
　マルチコアプロセッサの利用形態として、同種ないし異種のＯＳを複数稼動させることは、システム全体の信頼性、応答性を改善する手段として有用である。
　他方、マルチコアプロセッサ上の複数ＯＳ間で、ＤＭＡコントローラ、グラフィックアクセラレータ、マルチメディア専用エンジン、ＨＤＤ（ハードディスク）コントローラ等の周辺デバイス（以下単に、デバイスと称する）を共有して利用することは容易ではない。その理由は、通常、デバイス管理はＯＳの役割としてそのＯＳ内で閉じており、あるＯＳの管理下にあるデバイスに対し、他のＯＳからアクセスされることは想定されていないためである。
　複数ＯＳ間でデバイスを共有して利用する手法としては、非特許文献１及び非特許文献２に記載されるようなクライアント-サーバ方式がある。このクライアント－サーバ方式は、デバイスにアクセスするＯＳを１つに限定したうえで、そのＯＳ上でアクセスサーバと呼ばれるサーバタスクを稼動させ、それ以外のＯＳ上のタスクは、ＯＳ間通信によってアクセスサーバと通信し、アクセスサーバにデバイスのアクセスを代行させる方式である。このアクセスサーバは、デバイスアクセスを代行する役割を果たすことから、プロキシと呼ばれることもある。
日経エレクトロニクス,　2005年3月28日号,　pp134-135 酒井　淳嗣　他,　情報処理　47巻1号,　情報処理学会,　2006年1月,　pp　29-33
　しかし、非特許文献１及び非特許文献２に記載のクライアント-サーバ方式には、次のような問題がある。
　第１の問題は、サーバへのデバイスアクセス要求のたびにプロキシつまりアクセスサーバへのタスク切り替えが必要なため、サーバを介したデバイスアクセスの性能が低下することである。これは特に、グラフィックアクセラレータやＨＤＤのように高速性が重視されるデバイスにおいて重大な問題となる。
　第２の問題は、デバイスアクセスの種類ごとにプロキシとなる機能をアクセスサーバに実装する必要があり、その開発コストが大きいことである。
　例えば、グラフィックアクセラレータやＨＤＤのような多機能デバイスに対しては、アプリケーション開発者向けに数十から数百のＡＰＩ（アプリケーションプログラムインタフェース）が用意されることも稀ではなく、これらに対するプロキシ及びそれを経由するようなスタブルーチンの開発には看過できないコストを必要とする。
［発明の目的］
　本発明の目的は、デバイスアクセス性能低下を抑えたＯＳ間デバイス共有を可能とするマルチプロセッサシステム、マルチプロセッサシステムのＯＳ間デバイス共有方法を提供することにある。
　本発明の他の目的は、ＯＳ間デバイス共有に要する開発コストを低く抑えることのできるマルチプロセッサシステム、マルチプロセッサシステムのＯＳ間デバイス共有方法を提供することにある。
　本発明によるマルチプロセッサシステムは、複数のＯＳが動作するマルチプロセッサシステムにおいて、複数のＯＳが、ＯＳ間で共有するデバイスにアクセスするデバイスドライバを有し、デバイスドライバが、ＯＳカーネル層でのＯＳ間通信を行う、デバイスインタフェース部と、タスクインタフェース部の少なくとも一方を有し、デバイスインタフェース部が、デバイスドライバの操作対象のデバイスとのアクセスを行い、タスクインタフェース部が、各ＯＳ上のタスクからのデバイスアクセス要求の受理とデバイスアクセス結果のタスクへの返却を行う。
　本発明によるデバイスドライバは、複数のＯＳが動作するマルチプロセッサシステムのＯＳ間で共有するデバイスにアクセスするＯＳが備えるデバイスドライバであって、デバイスドライバの操作対象のデバイスとのアクセスを行うデバイスインタフェース部と、デバイスインタフェース部とＯＳカーネル層でのＯＳ間通信を行い、各ＯＳ上のタスクからのデバイスアクセス要求の受理とデバイスアクセス結果のタスクへの返却を行うタスクインタフェース部の少なくとも一方を含む。
　本発明によるＯＳ間デバイス共有方法は、ＯＳ間で共有するデバイスにアクセスするデバイスドライバを有する複数のＯＳが動作するマルチプロセッサシステムのＯＳ間デバイス共有方法であって、デバイスドライバが、デバイスインタフェース部と、タスクインタフェース部の少なくとも一方を有し、タスクインタフェース部とデバイスインタフェース部とがＯＳカーネル層でのＯＳ間通信を行い、デバイスインタフェース部が、デバイスドライバの操作対象のデバイスとのアクセスを行い、タスクインタフェース部が、各ＯＳ上のタスクからのデバイスアクセス要求の受理とデバイスアクセス結果のタスクへの返却を行う。
　本発明の第１の効果は、クライアント-サーバ方式によるクライアント側タスクからのデバイスアクセス性能を向上させることである。
　本発明の第２の効果は、デバイス共有のためのソフトウェア開発コストを抑えることができることである。
本発明の第１の実施の形態によるシステム全体構成を示すブロック図である。 本発明の第１の実施の形態におけるＯＳ－Ａ及びＯＳ－Ｂ上のデバイスドライバの内部構成を示す図である。 本発明の第１の実施の形態における処理要求構造体の内部構成を示す図である。 本発明の第１の実施の形態におけるＯＳ－Ａ及びＯＳ－Ｂ上のデバイスドライバ間通信部の内部構成を示すブロック図である。 本発明の第１の実施の形態における呼出要求構造体の内部構成を示す図である。 本発明の第１の実施の形態における呼出要求リストの内部構成を示す図である。 本発明の第１の実施の形態におけるＯＳ－Ａ用デバイスドライバの初期設定手順を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ－Ｂ用デバイスドライバの初期設定手順を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ－Ａ用デバイスドライバの要求解釈部の動作を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ－Ａ用デバイスドライバの待機タスク再開部の動作を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ－Ｂ用デバイスドライバの要求解釈部の動作を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ－Ｂ用デバイスドライバの待機タスク再開部の動作を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ－Ａ用デバイスドライバのデバイス設定部の動作を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ－Ａ用デバイスドライバのデバイス割り込み処理部の動作を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ－Ａでのデバイスドライバ間通信部の初期設定手順を示すフローチャートである。 本発明の第１の実施の形態におけるデバイスドライバ間通信部が通信相手ＯＳを呼び出す動作を説明するフローチャートである。 本発明の第１の実施の形態におけるデバイスドライバ間通信部にて、相手ＯＳから呼び出された際の被呼出処理の動作を示すフローチャートである。 本発明の第１の実施の形態におけるＯＳ－Ａ上のユーザタスクがデバイスアクセスを行う際の処理フロー全体を示す図である。 本発明の第１の実施の形態におけるＯＳ－Ｂ上のユーザタスクがデバイスアクセスを行う際の処理フロー全体を示す図である。 本発明の第２の実施の形態におけるデバイスドライバ及びその内部の判定部の位置づけを示す図である。 本発明の第３の実施の形態におけるデバイスドライバ及びその内部の要求待ちリストの構成を示す図である。 本発明の第４の実施の形態によるＯＳ－Ａ及びＯＳ－Ｂ上のデバイスドライバの内部構成を示す図である。
　次に、本発明の実施の形態について図面を参照して詳細に説明する。
（第１の実施の形態）
［構成の説明］
　図１を参照すると、本発明の第１の実施の形態による複数のＯＳを搭載する共有メモリ型のマルチプロセッサシステムは、マルチコアプロセッサ１０と、２種類のＯＳである、ＯＳ－Ａ４０とＯＳ－Ｂ５０、各ＯＳ上のユーザタスク４３、５３、マルチコアプロセッサ１０の外部バス３０に接続されたメモリ３１を含む構成である。
　マルチコアプロセッサ１０は、２つのＣＰＵコアすなわちＣＰＵコア（０）２０とＣＰＵコア（１）２１、割り込み制御部１２、割り込みのうち特にＣＰＵコア間の割り込みを発生させるコア間割り込み発生部１３、ＯＳ間で共有する内部デバイス１４を備えて構成され、これらがプロセッサ内部バス１１で接続されている。
　ＣＰＵコア上のソフトウェアに目を向けると、ＣＰＵコア（０）２０上ではＯＳ－Ａ４０が稼動している。このＯＳ－Ａ４０には、内部デバイス１４をアクセスするためのデバイスドライバ４１が組み込まれ、そのＯＳ上には、内部デバイス１４をアクセスするユーザタスク（Ａ０）４３が存在する。
　また、ＯＳ－Ａ４０は、隣接する他のＯＳと通信するためのデバイスドライバ間通信部（Ａ）４２を有している。
　同様に、ＣＰＵコア（１）２１上ではＯＳ－Ｂ５０が稼動している。このＯＳ－Ｂ５０には、内部デバイス１４をアクセスするためのデバイスドライバ５１が組み込まれ、そのＯＳ上には、内部デバイス１４をアクセスするユーザタスク（Ｂ０）５３が存在する。
　ＯＳ－Ｂ５０は、隣接する他ＯＳと通信するためのデバイスドライバ間通信部（Ｂ）５２を有している。
　ここでは説明のために、マルチコアプロセッサ１０としてＣＰＵコアを２つ含み、その上で２種類のＯＳが動作している構成を図示しているが、本発明は２コア構成のマルチコアプロセッサに限定されず、複数のＣＰＵコアを含む構成であれば適用することが可能であり、また３種類以上のＯＳが動作する構成にも適用可能である。
　また、図１では、マルチコアプロセッサ１０の内部バス１１上と、外部バス３０上に、各々内部デバイス１４及び外部デバイス３２が接続されているが、そのデバイスの数や接続先の内部／外部の区別は、本発明を適用を妨げるものではない。更には、割り込み制御部１２やコア間割り込み発生部１３がマルチコアプロセッサ１０の外部バス３０に接続されていても、本発明をそのまま適用できる。
　以降もっとも典型的な例として、２コア構成のマルチコアプロセッサで、その内部バス上に接続された内部デバイス１４を２つのＯＳ間で共有する場合を取り上げて具体的に説明する。
　次に、本発明の主要な構成要素であるデバイスドライバの構造について説明する。
　図２を参照すると、ＯＳ－Ａ４０に組み込まれるＯＳ－Ａ用デバイスドライバ４１は、ユーザタスク（Ａ）４３からの要求を受け付け、処理結果をユーザタスク（Ａ）４３に返却するための、タスクインタフェース部（Ａ）４４と、内部デバイス１４の動作を制御しあるいはその状態を観察し、デバイスからの結果を受け取るデバイスインタフェース部（Ａ）４５と、タスクインタフェース部（Ａ）４４がユーザタスクから受け付けたものの、まだ対象デバイスである内部デバイスが処理を開始していない処理要求を格納しておく領域である要求待ちリスト４６と、対象デバイスが現在実行中の処理情報を格納しておく領域である処理中リスト４７とを備える。
　タスクインタフェース部（Ａ）４４は、その内部に、ユーザタスク（Ａ）４３からの処理要求を受け付ける要求解釈部（Ａ）４４１と、ユーザタスクの動作を制御しユーザタスク（Ａ）４３に処理結果を返すための待機タスク再開部（Ａ）４４２とを備える。
　デバイスインタフェース部（Ａ）４５は、その内部に、内部デバイス１４のレジスタ等に値を設定し、また他のＯＳ上のデバイスドライバからの通信割り込みを取り扱うデバイス設定部４５１と、内部デバイス１４からの割り込みを取り扱うデバイス割り込み処理部４５２とを備える。
　ＯＳ－Ａ４０は、その内部に、ＯＳ－Ａ用デバイスドライバ４１のほか、他のＯＳ上のデバイスドライバとの間で通信を行うデバイスドライバ間通信部（Ａ）４２を備える。また、ＯＳ－Ａ４０上では、内部デバイス１４へのアクセス要求を発行するユーザタスク（Ａ０）４３が動作している。
　内部デバイス１４は、与えられた処理が完了した等の状態変化をＯＳ側に伝えるため、ＣＰＵコアに対して割り込みを発生させる割り込み制御部１２に接続されている。
　ＯＳ－Ｂ５０は、デバイスインタフェース部（Ａ）４５及びそれに付随するデータ構造（要求待ちリスト４６、処理中リスト４７）を有していない点を除けば、ＯＳ－Ａ４０内部の構造と類似している。以下、同じく図２を参照してＯＳ－Ｂ内部の構成を説明する。
　ＯＳ－Ｂ５０に組み込まれたＯＳ－Ｂ用デバイスドライバ５１は、ユーザタスク（Ｂ）５３からの要求を受け付け、処理結果をユーザタスク（Ｂ）５３に返却するための、タスクインタフェース部（Ｂ）５４を備える。また、ＯＳ－Ｂ５０は、ＯＳ－Ｂ用デバイスドライバ５１とＯＳ－Ａ用デバイスドライバ４１との間の通信を行うためのデバイスドライバ間通信部（Ｂ）５２を備える。
　タスクインタフェース部（Ｂ）５４は、その内部に、ユーザタスク（Ｂ）５３からの処理要求を受け付ける要求解釈部（Ｂ）５４１と、ユーザタスクの動作を制御し、ユーザタスクに処理結果を返すための待機タスク再開部（Ｂ）５４２とを備える。
　上記で述べた構造すなわち、デバイスドライバをタスクインタフェース部とデバイスインタフェース部で構成し、デバイスを直接アクセスするＯＳ（ＯＳ－Ａ４０）にはその両者を搭載し、それ以外のＯＳ（ＯＳ－Ｂ５０）にはタスクインタフェース部のみのデバイスドライバを搭載し、デバイスを直接アクセスしないＯＳのタスクインタフェース部とデバイスを直接アクセスするＯＳのデバイスインタフェース部とをデバイスドライバ間通信で接続する方式が、本発明の中枢をなす特徴的な構成である。
　要求待ちリスト４６と、処理中リスト４７は、図３に示す処理要求構造体７０をデータ要素とし、これらがリストでつながったものとして構成される。処理要求構造体７０のインスタンスは、各ＯＳ上のデバイスドライバのタスクインタフェース部の要求解釈部にて作成され、要求待ちリスト４６につなげられる。
　対象の内部デバイスでの処理が開始されるときに、当該処理要求構造体７０のインスタンスは、要求待ちリスト４６から取り除かれ、処理中リスト４７に移される。
　最後に、各ＯＳ上のデバイスドライバのタスクインタフェース部の待機タスク再開部が、処理中リスト４７中の処理要求構造体のインスタンスを取り除き、呼び出し元のユーザタスクに処理結果を返す。
　最も基本的な構成では、デバイスに対する処理がユーザタスクからの要求順に実行されるように設計する。その場合、要求待ちリスト４６と処理中リスト４７は先入れ先出しすなわちＦＩＦＯとして実装することが考えられる。
　再び図３を参照すると、処理要求構造体７０は内部に次のようなフィールドを有する。
　処理要求識別子７１は、処理要求構造体７０のインスタンスを一意に区別するための識別子である。要求元ＯＳ識別子７２は、この処理を要求したユーザタスクが実行されていたＯＳを特定するための識別子であり、図２の例で言えば、ＯＳ－Ａ４０あるいはＯＳ－Ｂ５０を指す識別子となる。要求元タスク識別子７３は、この処理を要求したユーザタスクを、当該ユーザタスクを稼動させていたＯＳ内において、一意に特定するための識別子であり、例えば各ＯＳが管理するタスクＩＤそのものが用いられる。
　デバイス設定情報７４は、ユーザタスクからの要求に沿ってデバイスドライバが対象の内部デバイスに対して設定すべき値に関する情報を保持する。このデバイス設定情報７４は、例えば、デバイスドライバがＤＭＡコントローラであれば、転送元アドレスと転送先アドレスと転送サイズであり、デバイスドライバがグラフィックアクセラレータであれば、３Ｄ描画コマンド列である。
　従って、このデバイス設定情報７４が保持する内容はデバイスによって大きく異なるが、ある特定のデバイスに対する処理要求識別子７１では、そのデバイス設定情報７４は常に同一サイズとする。これにより処理要求構造体７０のインスタンスのメモリ管理が容易になる。デバイス設定情報７４の領域は、デバイス設定情報として現実的に想定される最大サイズのデータが保持できるサイズとし、もし必要であれば、処理要求内容を複数の処理要求識別子に分割して表現する。この分割はタスクインタフェース部４４、５４が行う。
　デバイス状態７５は、ユーザ要求を内部デバイスが処理した結果を格納するためのフィールドである。このデバイス状態７５に格納される内容は、例えば、ＤＭＡコントローラやグラフィックアクセラレータの場合には、要求処理が成功したか否かを示す単純な整数値であるが、ＨＤＤコントローラの場合、ＨＤＤから読み出したデータ列のように、大きなサイズのデータである場合もある。
　デバイス状態７５には、後続のデバイス処理によって上書きされ、あるいは後続のデバイス処理の開始が妨げられる等の理由により、デバイスからの完了割り込みがＯＳ側に伝達された後、速やかにデバイス内から取り出さなければならないデータのみを保持するように設計する。また、このデバイス状態７５のサイズは、ある特定のデバイスに対しては常に同一サイズとなるように設計する。これはデバイス設定情報７４の場合と同じく、メモリ管理を容易にするためである。
　次に、本実施の形態におけるデバイスアクセス性能改善に重要な役割を果たす、デバイスドライバ間通信部の構成について、図４を参照して説明する。なお、デバイスドライバ間通信部は各ＯＳに１つずつ存在するが、いずれも同じ構成である。以下では、ＯＳ－Ａ４０側のデバイスドライバ間通信部（Ａ）４２について説明するが、ＯＳ－Ｂ５０側のデバイスドライバ間通信部（Ｂ）５２も同様の構成である。
　本実施の形態におけるデバイスドライバ間通信は、事前にあるＯＳ側にて登録しておいたルーチンを他のＯＳ側から呼び出す、という点において、リモートプロシージャコール（ＲＰＣ）と類似の概念で通信を行う。しかし、本実施の形態におけるデバイスドラバ間通信は、ほとんどの部分が割り込みハンドラ内で実行されることが特徴であり、これにより通信オーバヘッドを低減する効果をもたらす。
　ＯＳ－Ａ４０側のデバイスドライバ間通信部（Ａ）４２は、事前のルーチン登録に関連して、ＯＳ－Ａ４０側の登録済みルーチンを保持する被呼出ルーチン登録表（Ａ）４２２と、その表に対して事前にルーチンを登録するための被呼出ルーチン登録部（Ａ）４２１を備える。
　デバイスドライバ間通信部（Ａ）４２はまた、他ＯＳ側から呼び出された状況の管理に関連して、ＯＳ－Ａ側の登録済みルーチンに対する未実行の呼出要求をリストで管理する呼出要求リスト（Ａ）４２３と、デバイスドライバ間通信部（Ａ）４２が現在、登録済みルーチンのいずれかを呼び出しているか否かを示す被呼出状態記憶部（Ａ）４２４を備える。
　デバイスドライバ間通信部（Ａ）４２は、また、相手を呼び出すあるいは相手から呼び出される、という動作に関連して、次の２つの処理部を備える。
　すなわち、ＯＳ－Ａ用デバイスドライバ４１からの要求に応じ、コア間割り込みを発生させて他のＯＳ上のデバイスドライバ間通信部を呼び出す処理を行う呼出処理部（Ａ）４２６と、コア間割り込みを経て他のＯＳから要求されたことを受け、登録済みルーチン呼出し処理を行う、被呼出処理部（Ａ）４２５である。
　被呼出処理部（Ａ）４２５は、通信高速化のため、割り込みハンドラ内の処理として、ＯＳ－Ａ４０の割り込み受け付け部４８から直接呼び出されることが望ましい。
　しかし、割り込み禁止時間をできるだけ減らし、割り込みハンドラをできるだけ軽量にするためには、被呼出処理部（Ａ）４２５の処理の多くをカーネルタスクすなわちＯＳカーネル内で動作するタスクないしスレッドとして実装し、ＯＳ－Ａ４０の割り込み受付部４８は前記カーネルタスクの起動だけを行う構成も可能である。
　呼出要求リスト（Ａ）４２３には、図５に示される呼出要求構造体８０のインスタンスが格納される。この呼出要求構造体８０は、要求元ＯＳ識別子８１と、呼出ルーチン識別子８２と、呼出パラメータ８３の３つのフィールドを備える。
　要求元ＯＳ識別子８１は、この処理を要求したデバイスドライバが実行されていたＯＳを特定するための識別子であり、図２の例で言えば、ＯＳ－Ｂ５０を指す識別子となる。本実施の形態ではＯＳ－Ａ４０以外のＯＳはＯＳ－Ｂ５０ただ一つであるため、要求元ＯＳ識別子８１は、ＯＳ－Ｂ５０以外の値になり得ないが、３つ以上のＯＳが動作する場合には、要求元ＯＳ識別子８１は複数の値をとりうる。
　次に、呼出ルーチン識別子８２は、被呼出ルーチン登録表４２２に登録済みのルーチンのなかの１つを指定するものである。
　呼出パラメータ８３は、被呼出ルーチンを実行する際のパラメータ（引数）群を格納する領域である。パラメータ群は一般には呼出ルーチン毎に異なるが、できるだけ少数かつ小さいサイズのパラメータで済むよう呼出ルーチンを設計することで、呼出パラメータ８３のフィールドを小さい固定サイズとすることが望ましい。これはデバイス設定情報７４の場合と同じく、メモリ管理を容易にするためである。
　呼出要求リスト（Ａ）４２３は、図６に示されるように、呼出要求構造体８０のインスタンスがＦＩＦＯ状に格納されるリスト構造である。図６の例では、呼出要求構造体８０が呼出要求構造体（１）８０－１、呼出要求構造体（２）８０－２、呼出要求構造体（３）８０－３・・・の順番に格納されており、呼出要求構造体（１）８０－１、呼出要求構造体（２）８０－２、呼出要求構造体（３）８０－３の順に取り出される。
［動作の説明］
　上述した第１の実施の形態の動作について、まず初期設定から説明する。初期設定は、デバイスドライバ間通信部（Ａ）４２および（Ｂ）５２、ＯＳ－Ａ用デバイスドライバ４１、ＯＳ－Ｂ用デバイスドライバ５１の各々について行う。
　デバイスドライバ間通信部（Ａ）４２および（Ｂ）５２の初期設定について、図１５を参照して説明する。
　図１５を参照すると、デバイスドライバ間通信部（Ａ）４２の初期設定は、ＯＳのコマ間割込みハンドラとして被呼出処理部（Ａ）４２５を登録するステップ２０６と、被呼出状態記憶部（Ａ）４２４の処理中フラグをオフ（クリア）するステップ２０７から成る。デバイスドライバ間通信部（Ｂ）５２も上記と同様に、ＯＳのコマ間割込みハンドラとして被呼出処理部（Ｂ）５２５を登録するステップと、被呼出状態（Ｂ）５２４をクリアするステップから成る。
　ＯＳ－Ａ用デバイスドライバ４１の初期設定について、図７を参照して説明する。
　図７を参照すると、ＯＳ－Ａ用デバイスドライバ４１の初期設定は、次の３つのステップで実行される。
　まず、ステップ２０１で、内部デバイス１４からの割込みハンドラとして、図２のデバイス割り込み処理部４５２内のデバイス完了割込処理ルーチンを登録する。この処理はＯＳ－Ａ４０の機能を利用して実行する。
　次に、ステップ２０２で、ＯＳ－Ａ４０におけるデバイスドライバ間通信の被呼出ルーチンの一つとして、後述のデバイス設定ルーチンを登録する。この登録は、デバイスドライバ間通信部（Ａ）４２の被呼出ルーチン登録部（Ａ）４２１（図４）を呼び出すことにより実行する。
　最後に、ステップ２０３で、ＯＳ－Ａ用デバイスドライバ４１内の要求待ちリスト４６と処理中リスト４７を共に空にする。
　ＯＳ－Ｂ用デバイスドライバ５１の初期設定について、図８を参照して説明する。
　図８を参照すると、ＯＳ－Ｂ用デバイスドライバ５１の初期設定は、次のステップからなる。すなわち、ステップ２１１にて、ＯＳ－Ｂ５０におけるデバイスドライバ間通信の被呼出ルーチンの一つとして、後述のタスク再開Ｂルーチンを登録する。この登録は、デバイスドライバ間通信部（Ｂ）５２の被呼出ルーチン登録部（Ｂ）５２１（図４）を呼び出すことによって実行する。
　以上が初期設定の動作の説明である。次に各デバイスドライバのタスクインタフェース部の動作を説明する。
　まず、ＯＳ－Ａ４０側のタスクインタフェース部（Ａ）４４について説明する。前述のように、タスクインタフェース部（Ａ）４４は、要求解釈部（Ａ）４４１と待機タスク再開部（Ａ）４４２から成る。
　ユーザタスク４３からのデバイスアクセス要求があると、まず要求解釈部（Ａ）４４１が呼び出される。その要求解釈部（Ａ）４４１での処理の流れを図９に示す。
　要求解釈部（Ａ）４４１は、まず、ステップ２２１にて処理要求構造体７０の新しいインスタンスを作成する。処理要求構造体７０の構造は図３に示した通りである。
　ステップ２２１で作成された処理要求構造体７０のインスタンスでは、処理要求識別子フィールド７１は、このデバイスドライバ内でユニークな整数値に設定され、要求元ＯＳ識別子フィールド７２は、ＯＳ－Ａを意味する値に設定され、要求元タスク識別子フィールド７３は、今回のデバイスアクセス要求を行ったユーザタスク４３のタスクＩＤが設定される。
　また、デバイス設定情報フィールド７４には、今回のデバイスアクセス要求の種類、パラメータ等、デバイスドライバのデバイスインタフェース部（Ａ）４５が内部デバイス１４に対して行う操作を特定するための情報が格納される。デバイス状態フィールド７５にはこの時点では何も設定されない。
　要求解釈部（Ａ）４４１は、次に、上で作成した処理要求構造体インスタンスを、ＯＳ－Ａ用デバイスドライバ内の要求待ちリスト４６に登録する。この要求待ちリスト４６は、ＯＳ－Ａのタスクインタフェース部（Ａ）４４、ＯＳ－Ｂのタスクインタフェース部（Ｂ）５４、更にＯＳ－Ａのデバイス割り込み処理部４５２からアクセスされるため、図９のステップ２２２からステップ２２５にあるように、割り込みを禁止した上で、排他制御すなわちロック－アンロック操作で保護した区間内で実際の登録操作（ステップ２２４）を行う。
　ここで、ロック－アンロック操作は例えば、ＯＳが提供する排他制御サービス関数ないしＣＰＵが有する排他制御命令を組み合わせた命令列を用いて行なう。このときのロック操作はビジーウェイト型すなわち、既にロック中の場合はロックが確保できるまで繰り返しロックを試みる形式で行う。ビジーウェイト型でロックを行うのは、本実施の形態では排他制御区間が短いため、もし他者が排他制御区間内を実行中であってもすぐに排他制御区間を抜けることが期待されるからである。ただし、システムの特性により、ロック獲得試行を一定時間試みた上で獲得に成功しなければステップ２２３をタイムアウトし、図９の処理要求全体をエラーで終了させる、という実装の形態をとることも可能である。
　次に、要求解釈部（Ａ）４４１は、ステップ２２６にて、同じデバイスドライバ内のデバイス設定部４５１に格納された処理である、デバイス設定ルーチンを呼び出す。このデバイス設定ルーチンの動作は後述するが、その概要は、要求待ちリスト４６から次の処理要求構造体を取り出して内部デバイス１４を適切に設定する、という処理である。
　その後、要求解釈部（Ａ）４４１は、ステップ２２７で割り込みを許可し、ステップ２２８でＯＳ－Ａのサービス関数を用いてユーザタスク（Ａ０）４３を待ち状態（スリープ状態）に遷移させる。
　これによりＯＳ－Ａは呼び出し元ユーザタスク（Ａ０）４３の実行を中断し、別の実行可能ユーザタスクがあれば、そのタスクにタスク切り替えすることになる。以上が要求解釈部（Ａ）４４１の動作の流れである。
　デバイスでの処理が終わると、デバイス割り込み処理部４５２が、その処理結果を処理要求構造体７０のデバイス状態フィールド７５に格納して、タスクインタフェース部（Ａ）４４の待機タスク再開部（Ａ）４４２を呼び出す。この一連の処理は後述するが、ここでは、図１０を用いてその待機タスク再開部（Ａ）４４２の動作の流れを説明する。
　まず、ステップ２３１で、処理要求構造体７０のデバイス状態フィールド７５からデバイス処理結果を読み出し、呼び出し元ユーザタスク（Ａ０）４３内の所定のメモリ領域にデバイス処理結果をコピーする。ＵＮＩＸなどＯＳカーネルとユーザタスクが別の論理メモリ空間で動作するＯＳの場合、このコピーは、カーネル空間からユーザタスク空間へのコピーを実行する、ＯＳ提供のサービス関数を呼び出すことで行う。
　次に、ステップ２３２で、前述のステップ２２１で確保した処理要求構造体７０のメモリを解放し、最後にステップ２３３で、ＯＳ－Ａ４０のサービス関数を用いてユーザタスク（Ａ０）４３を実行可能状態に遷移させる。
　これにより、ＯＳ－Ａ４０は、デバイス処理待ちで中断していたユーザタスク（Ａ０）４３の実行を再開することになる。以上が待機タスク再開部（Ａ）４４２の動作の流れである。
　次に、ＯＳ－Ｂ５０側のタスクインタフェース部（Ｂ）５４を説明する。前述のように、タスクインタフェース部（Ｂ）５４は、要求解釈部（Ｂ）５４１と待機タスク再開部（Ｂ）５４２から成る。これらはＯＳ－Ａ４０側の対応する部分と類似する動作を行うが、要求待ちリスト、処理中リスト、及びデバイスインタフェース部とのやりとりに関しＯＳ－Ａ側に対して働きかける点が異なっている。
　ＯＳ－Ｂ５０上のユーザタスク（Ｂ０）５３からデバイスアクセス要求があると、まず要求解釈部（Ｂ）５４１が呼び出される。その要求解釈部（Ｂ）５４１での処理の流れを図１１に示す。
　要求解釈部（Ｂ）５４１は、まずステップ２４１にて処理要求構造体７０の新しいインスタンスを作成する。このステップはＯＳ－Ａ４０側での対応する処理であるステップ２２１と同様であるが、要求元ＯＳ識別子フィールド７２にはＯＳ－Ｂ５０を識別する値が設定される。
　次に、要求解釈部（Ｂ）５４１は、上で作成した処理要求構造体７０のインスタンスを、ＯＳ－Ａ用デバイスドライバ４１内の要求待ちリスト４６に登録する。ＯＳ間排他制御のため、図１１のステップ２４２、ステップ２４４にあるように、ロック－アンロック操作で保護した区間内で実際の登録操作（ステップ２４３）を行う。
　ロック－アンロック操作の実装については、図９に示したＯＳ－Ａ側の処理（ステップ２２３、ステップ２２５）と同様である。すなわち、ＯＳが提供する排他制御サービス関数ないしＣＰＵが有する排他制御命令を組み合わせた命令列を用いてロック及びアンロック操作を行なう。
　要求解釈部（Ｂ）５４１は、次にステップ２４５にて、以下のパラメータを指定してデバイスドライバ間通信部（Ｂ）５２を呼び出すことで、ＯＳ－Ａ側のデバイスインタフェース部（Ａ）のデバイス設定ルーチンを遠隔呼び出しする。
　呼出先ＯＳ＝ＯＳ－Ａ、呼出ルーチン識別子＝デバイス設定ルーチンの識別子（ステップ２０２で登録したもの）、呼出パラメータ＝なし
　デバイスドライバ間通信部の動作については後述する。
　その後、要求解釈部（Ｂ）５４１は、ステップ２４６でＯＳ－Ｂ５０のサービス関数を用いてユーザタスク（Ｂ０）５３を待ち状態（スリープ状態）に遷移させる。
　これにより、ＯＳ－Ｂ５０は呼び出し元ユーザタスク（Ｂ０）５３の実行を中断し、別の実行可能ユーザタスクがあれば、そのタスクにタスク切り替えすることになる。以上が要求解釈部（Ｂ）５４１の動作の流れである。
　デバイスでの処理が終わるとＯＳ－Ａ４０側に割り込みが入り、デバイス割り込み処理部４５２がデバイス処理結果を処理要求構造体７０のデバイス状態フィールド７５に格納して、その処理要求構造体インスタンスを引数としてタスクインタフェース部（Ｂ）５４の待機タスク再開部（Ｂ）５４２を呼び出す。この一連の処理は後述するが、ここでは図１２を用いてその待機タスク再開部（Ｂ）５４２の動作の流れを説明する。
　まずステップ２５１で、引数として与えられた処理要求構造体７０のデバイス状態フィールド７５からデバイス処理結果を読み出し、呼び出し元ユーザタスク（Ｂ０）５３内の所定のメモリ領域にデバイス処理結果をコピーする。ＵＮＩＸなどＯＳカーネルとユーザタスクが別の論理メモリ空間で動作するＯＳの場合、このコピーは、カーネル空間からユーザタスク空間へのコピーを実行する、ＯＳ提供のサービス関数を呼び出すことにより行う。
　次にステップ２５２で、前述のステップ２４１で確保した処理要求構造体７０のメモリを解放し、最後にステップ２５３で、ＯＳ－Ｂ５０のサービス関数を用いてユーザタスク（Ｂ０）５３を実行可能状態に遷移させる。
　これにより、ＯＳ－Ｂ５０は、デバイス処理待ちで中断していたユーザタスク（Ｂ０）５３の実行を再開することになる。以上が各デバイスドライバのタスクインタフェース部の動作の説明である。
　次に、ＯＳ－Ａ側デバイスドライバ４１に固有のデバイスインタフェース部（Ａ）４５の動作を説明する。前述のように、デバイスインタフェース部（Ａ）４５は、デバイス設定部４５１とデバイス割り込み処理部４５２から成る。
　図１３を参照して、デバイス設定部４５１の動作の流れを説明する。デバイス設定部４５１は割り込み禁止状態で呼び出されることが想定されている。
　ステップ２６１～ステップ２６３にて、デバイス設定のループ処理の継続条件を判断する。要求待ちリスト４６に処理要求構造体が全く存在しない場合、あるいは、ループ継続の繰り返し回数が所定の上限値を越えている場合、あるいは、内部デバイス１４が既に処理中で、新たな処理が受け付けられない状態の場合は、ループを抜け、デバイス設定処理を終了する。
　ここで、ループ継続の上限値は、デバイス設定を繰り返すことで割り込み禁止区間が長引き、他の処理（例えばＯＳのタスク切り替えやリアルタイム処理）に悪影響を及ぼすことを防ぐために設定されるものである。
　内部デバイスがｎ種類の処理要求を同時に受け付けられるのであれば、ループ継続上限値はｎないしそれ未満の値に設定する。他方、内部デバイスがせいぜい1つの処理要求しか受け付けられないなら、ループ継続上限値は１固定となる。
　また、前記趣旨から、ループ継続上限値に代えて、本デバイス設定処理に費やした時間の上限値を用いる実施形態も考えられる。この場合、デバイス設定処理の開始時にタイマ等により現在時刻を取得し、ステップ２６２にて再度タイマ等により現在時刻を取得して開始時刻からの経過時刻を算出し、その値が上限値を越えていたらデバイス設定を終了する、という動作の流れになる。
　ステップ２６４～ステップ２６６にて、要求待ちリストから１つの処理要求構造体インスタンスを取り出す。取り出すインスタンスは、要求待ちリスト内に蓄積されている全インスタンスの中から、一定ルールで選び出す。例えば、時間的に先に到着したものを先に取り出す（ＦＩＦＯ）というルールを用いる。
　また、要求待ちリストは本デバイス設定部以外にＯＳ－Ａ４０及びＯＳ－Ｂ５０のタスクインタフェース部からもアクセスされるため、排他制御のためのロック－アンロック操作を前後にはさむ。このロック－アンロックは、ＯＳによる排他制御サービス関数呼び出しあるいはＣＰＵが有する排他制御命令の組み合わせで実現される。このロック操作はビジーウェイト型すなわち、既にロック中の場合はロックが確保できるまで繰り返す形式で行う。ＯＳのサービス関数を使う場合は、割り込みハンドラから安全に呼び出せるものに限る。
　ステップ２６７にて、処理要求構造体７０のデバイス設定情報フィールド７４を参照して、内部デバイス１４に対して設定値を書き込み、内部デバイス１４を目的の動作状態に遷移させる。
　このステップ２６７は対象となるデバイスごとに異なる実装になるが、例えばＤＭＡコントローラであれば、転送元アドレスレジスタ、転送先アドレスレジスタ、転送サイズレジスタに設定値を書き込み、制御レジスタの所定ビットを設定してＤＭＡ転送を開始させる、といった処理を行う。また他の例としてグラフィックアクセラレータをとりあげると、デバイス設定情報フィールド７４の内容に従ってワークメモリ上に描画コマンド列を作成し、制御レジスタの所定ビットを設定することで、グラフィックアクセラレータの描画処理を起動する、といった処理を行う。これらの処理は、関連技術のデバイスドライバ、例えば一般的なＤＭＡデバイスドライバ、グラフィックアクセラレータデバイスドライバがそれぞれの内部デバイスに対して行っている処理と同様である。
　内部デバイス１４が複数の処理要求を受け付けるタイプのデバイスである場合、ステップ２６７では上記に加え、デバイスに投入した複数の処理を識別するための識別子の値を、処理要求構造体７０の処理要求識別子フィールド７１に設定する。この識別子はデバイスによって異なるが、例えばトランザクションＩＤやコマンドキューイングＩＤなどである。
　最後にステップ２６８にて、前述のステップ２６５で取り出した処理要求構造体７０のインスタンスを、処理中リスト４７に登録する。処理中リスト４７はＯＳ－Ａのタスクインタフェース部（Ａ）４４からもアクセスされるが、タスクインタフェース部（Ａ）４４とデバイスインタフェース部４５とは、割り込み禁止/許可操作によって既に排他制御が行われているため、ステップ２６８前後には特段の排他制御処理は不要である。
　以上が、デバイス設定部４５１の動作の流れの説明である。
　次に、図１４を参照して、デバイス割り込み処理部４５２の動作の流れを説明する。デバイス割り込み処理部４５２は、内部デバイスからＯＳ－Ａ４０への割り込みに対するハンドラとして呼び出されるため、その処理全体が割り込み禁止状態で実行される。
　まずステップ２７１にて、すみやかに内部デバイス１４からデバイス状態を読み出す。これは、デバイスに対する次の外部イベント、例えば後続のグラフィック描画処理の完了や後続のディスク読み出し処理の完了等が起きてデバイス状態が変化してしまうことを回避すること、あるいはシリアルポート等、デバイスによってはデバイス状態を読み出さない限り次のデバイス処理が進まないことがあり、その事態を回避すること、などの理由による。
　ステップ２７２にて、処理中リスト４７から、今回の完了割り込みに対応する処理要求構造体７０のインスタンスを取り出す。内部デバイス１４が複数の処理要求を受け付けるタイプのデバイスである場合、前述のステップ２６７で設定した処理要求識別子フィールド７１の値を内部デバイス側と照合することで、対応する処理要求構造体７０のインスタンスを一意に特定する。
　ステップ２７３にて、ステップ２７１で読み出したデバイス状態の値を、ステップ２７２で取り出した処理要求構造体７０のデバイス状態フィールド７５に格納する。これにより、内部デバイスの処理完了後の状態が処理要求構造体７０のインスタンス内に退避できたことになる。
　ステップ２７４にて、処理要求構造体インスタンスの要求元ＯＳ識別子７２を参照して要求元ＯＳを判断する。
　もし要求元ＯＳがＯＳ－Ａ４０であった場合、ステップ２７５にて、前記処理要求構造体７０のインスタンスを引数として、待機タスク再開部（Ａ）４４２を呼び出す。待機タスク再開部Ａでの処理の流れは、図１０のステップ２３１からステップ２３３で説明した通りである。この操作により、デバイス処理完了を待っていたＯＳ－Ａ４０上の呼び出し元ユーザタスク（Ａ０）４３の動作が再開される。
　もし要求元ＯＳがＯＳ－Ａ以外であった場合、ステップ２７７にて、以下のパラメータを指定してデバイスドライバ間通信部（Ａ）４２を呼び出すことで、要求元ＯＳのデバイスインタフェース部の待機タスク再開部を遠隔呼び出しする。
　呼出先ＯＳ＝要求元ＯＳ、呼出ルーチン識別子＝要求元ＯＳのタスク再開ルーチンの識別子（ステップ２１１で登録したもの）、呼出パラメータ＝前記処理要求構造体インスタンス
　この操作により、要求元ＯＳ上でデバイス処理完了を待っていた呼び出し元ユーザタスク（この説明の例ではユーザタスク（Ｂ０）５３）の動作が再開される。
　最後にステップ２７６にて、デバイス設定部４５１にあるデバイス設定ルーチンを呼び出し、次の処理を内部デバイス１４に設定する。この部分の動作は、図１３のステップ２６１からステップ２６８にて説明した通りである。
　以上がＯＳ－Ａ側にあるデバイスインタフェース部４５の動作の説明である。
　次に、異なるＯＳ上のデバイスドライバ間で直接通信を行う、デバイスドライバ間通信部（Ａ）４２、（Ｂ）５２の動作の流れについて説明する。１組の通信は片方のデバイスドライバからもう片方のデバイスドライバへの単方向通信であり、同種のものを２組用いることで双方向通信を実現することができる。そこで以下では１組の単方向通信の動作について説明する。
　デバイスドライバ間通信部（Ａ）４２、（Ｂ）５２は、遠隔呼び出しのためのパラメータ、すなわち、通信相手のＯＳと、そのＯＳ上で呼び出したい呼出ルーチン識別子、及びそのルーチンに渡す呼出パラメータ、の３つを指定して各ＯＳのデバイスドライバから呼び出される。
　図１６を参照すると、デバイスドライバ間通信部（Ａ）４２、（Ｂ）５２はまずステップ２８１にて、与えられたパラメータのうち、呼出ルーチン識別子と呼出パラメータの２つを用いて図５に示す呼出要求構造体８０のインスタンスを作成する。要求元ＯＳ識別子フィールド８１には、呼び出し元のＯＳを識別する値を設定する。
　ステップ２８３では上記呼出要求構造体８０のインスタンスを、呼び出す相手ＯＳの呼出要求リスト（Ａ）４２３又は（Ｂ）５２３に追加する。この呼出要求リストは相手ＯＳからもアクセスされるため、排他制御のために直前のステップ２８２にてロックを獲得する。このロックはＣＰＵ自身が備える排他制御命令あるいはそれ相当のＯＳサービス関数で行う。
　ステップ２８４にて、相手ＯＳのデバイスドライバ間通信部が処理中か否かを判断する。これは相手側のデバイスドライバ通信部内の被呼出状態記憶部（図４の４２４ないし５２４）の処理中フラグを直接参照することで判断する。
　もし相手のデバイスドライバ間通信部が処理中でなければ、ステップ２８５にて、相手ＯＳへのコア間割り込みを発生させる。これはＣＰＵ自身のハードウェア操作命令ないしそれに相当するＯＳサービス関数により、コア間割り込み発生部１３に対して相手ＯＳが動作するＣＰＵコアへのＣＰＵコア間割り込みを要求することで行う。これにより相手のデバイスドライバ間通信部が呼出要求リスト５２３、５２３内に蓄積されている新規要求を処理し始める。これはすぐ後で説明する。
　もし相手のデバイスドライバ間通信部が処理中であれば、ステップ２８３で呼出要求リスト４２３、５２３に追加した要求がやがて処理されるので、ステップ２８５は単純にスキップして次へ進む。
　ステップ２８６にて、ステップ２８２で獲得したロックをアンロックし、排他制御区間を抜ける。
　ステップ２８５で相手ＯＳへのコア間割り込みを起こすと、相手ＯＳ側では、図１５のステップ２０６で設定した被呼出処理部が呼び出される。この被呼出処理部の動作の流れを図１７を参照して説明する。以下の被呼出処理部の説明においては、この相手ＯＳすなわち被呼出側ＯＳのことを「自ＯＳ」と呼ぶ。
　被呼出処理部４２５、５２５は、ステップ２９２にて自ＯＳの呼出要求リスト４２３、５２３を調べ、それが空であれば、ステップ２９７にて被呼出状態記憶部（図４の４２４ないし５２４）の処理中フラグをオフ（処理中でない）にして、被呼出処理部４２５、５２５全体の処理を終える。
　もし呼出要求リスト４２３、５２３が空でなければ、ステップ２９３にて呼出要求リスト４２３、５２３の先頭から呼出要求構造体８０のインスタンスを１つ取り出し、ステップ２９４にて被呼出状態記憶部（図４の４２４ないし５２４）の処理中フラグをオン（処理中）にしてから、ステップ２９６にて事前登録済みルーチンを呼び出す。
　ここで呼出要求リスト（図４の４２３ないし５２３）は呼出元のデバイスドライバ間通信部でもアクセスする可能性があるため、ステップ２９２からステップ２９４およびステップ２９７をロック－アンロックによる排他制御によって保護する。このロックはＣＰＵ自身が備える排他制御命令あるいはそれ相当のＯＳサービス関数で行う。
　再度ステップ２９６の説明に戻ると、ここでは、呼出要求構造体８０の呼出ルーチン識別子フィールド８２をキーとして自ＯＳ内の被呼出ルーチン登録表（図４の４２２ないし５２２）を検索することで、呼び出すべきルーチンを特定する。そして、呼出要求構造体８０の呼出パラメータフィールド８３に格納された値を前記ルーチンの引数として被呼出ルーチンの呼び出しを行う。
　以上が、デバイスドライバ間通信部による処理の流れの説明である。
　さらに理解を助けるために、各部の流れを通して示した図面を参照して、ＯＳ－Ａ４０上のタスクからのデバイスアクセス、ＯＳ－Ｂ５０上のタスクからのデバイスアクセスの様子について説明する。
　図１８は、ＯＳ－Ａ４０上で実行されている２つのタスクすなわちユーザタスク（Ａ０）とユーザタスク（Ａ１）が、あるデバイスを共有アクセスしている様子を示している。図１８において、上から下方向に時間が流れており、縦方向の細長い矩形はそのタスクや構成部分が動作している部分を示し、縦方向の細長い斜線ハッチング付きの矩形はその構成部分にデータ（インスタンス）が存在していることを示している。また、横方向の実線矢印はルーチンの呼出しや割り込みを示し、点線矢印はそれらの処理からの戻りを示している。
　図１８右上で、ユーザタスク（Ａ０）がデバイスに対して処理「ＸＸＸ」を要求している。この処理要求はＯＳ－Ａ４０のタスクインタフェース部（Ａ）４４から直接デバイス設定部４５１に到達し、デバイス設定部４５１が内部デバイス１４を設定して「ＸＸＸ」の処理が開始される。その「ＸＸＸ」処理が完了する前に、他のユーザタスク（Ａ１）から処理「ＹＹＹ」が要求されると、その要求はデバイス設定部４５１まで到達するが、内部デバイス１４は「ＸＸＸ」処理中のため、処理要求構造体７０が要求待ちリスト４６に入ったままになる。いずれの場合も、呼出元であるユーザタスク（Ａ０）、ユーザタスク（Ａ１）はＯＳ－Ａ４０上で待ち状態にされる。
　内部デバイス１４が「ＸＸＸ」処理を終えるとＯＳ－Ａ４０に対し割り込みが入り、ＯＳ－Ａ４０の割り込みハンドラからデバイス割り込み処理部４５２が呼び出される。
　デバイス割り込み処理部４５２は、内部デバイス１４の「ＸＸＸ」処理結果を処理中リスト４７に格納してからＯＳ－Ａタスクインタフェース部（Ａ）４４の待機タスク再開部（Ａ）４４２を呼び出す。
　待機タスク再開部（Ａ）４４２は、処理中リスト４７を読み出して処理結果を取得し、待ち状態になっていたユーザタスクＡ０を再開させる。デバイス割り込み処理部４５２は、更に、デバイス設定部４５１を呼び出して、要求待ちリスト４６で待機していた次の処理「ＹＹＹ」を取り出し、内部デバイス１４に設定する。
　その後、内部デバイス１４が「ＹＹＹ」処理も終えると、上と同様にＯＳ－Ａ４０に完了割り込みが入り、デバイス割り込み処理部４５２が処理結果を一旦処理中リスト４７に格納してから、タスクインタフェース部（Ａ）４４の待機タスク再開部（Ａ）４４２がユーザタスク（Ａ１）を再開させる。
　次に、図１９を参照して、デバイス操作を行うＯＳとは別のＯＳからデバイスアクセス要求を出す場合を説明する。ここではＯＳ－Ｂ５０上の２つのタスクすなわちユーザタスク（Ｂ０）とユーザタスク（Ｂ１）が、ＯＳ－Ａ４０側を介してデバイスにアクセスする場合を例にとって説明する。
　図１９右上にて、ユーザタスク（Ｂ０）とユーザタスク（Ｂ１）が相次いでデバイスアクセス要求「ＸＸＸ」及び「ＹＹＹ」をそれぞれ発行している。これらの要求はＯＳ－Ｂ５０側のタスクインタフェース部（Ｂ）５４で受理された後、デバイスドライバ間通信部（Ｂ）５２及び（Ａ）４２を介してＯＳ－Ａ４０側のデバイス設定部４５１に送り込まれる。
　このとき、デバイスドライバ間通信部（Ｂ）５２及び（Ａ）４２の内部で、コア間割り込み発生部１３によるＣＰＵコア間割り込みが使用され、ＯＳ－Ａ４０側の割り込みハンドラからデバイス設定部４５１が呼び出されている。デバイス設定部４５１が内部デバイス１４に対して設定を行う部分は、図１８の場合と同様である。
　内部デバイス１４が処理「ＸＸＸ」を終えると、図１８の場合と同様にＯＳ－Ａ４０に割り込みが入り、デバイス割り込み処理部４５２がデバイス完了割込処理を行うが、デバイス割り込み処理部４５２は処理要求構造体の要求元ＯＳ識別子を見て呼出元タスクがＯＳ－Ｂ５０であることを知り、デバイスドライバ間通信部（Ａ）４２及び（Ｂ）５２を用いてＯＳ－Ｂ５０側のタスクインタフェース部（Ｂ）５４を呼び出す。
　このとき、デバイスドライバ間通信（Ａ）４２及び（Ｂ）５２の内部で、コア間割り込み発生部１３によるＣＰＵコア間割り込みが使用され、ＯＳ－Ｂ５０側の割り込みハンドラから待機タスク再開部（Ｂ）５４２が呼び出されている。
　タスクインタフェース部Ｂの待機タスク再開部（Ｂ）５４２がユーザタスクを再開する部分は、図１８の場合と同様である。
（第１の実施の形態による効果）
　第１の実施の形態によれば、クライアント側であるＯＳ－Ｂ５０上のタスクからのデバイスアクセス性能を向上させることができる。その理由は、ＯＳ間の通信においてデバイスドライバ間での高速な通信手段を用いること、及びデバイスドライバ内のデータ構造を両デバイスドライバ間で直接アクセスすることで、通信を介したデータのやりとりを減少させたためである。
　また、デバイス共有のためのソフトウェア開発コストを低く抑えることができる。その理由は、ソフトウェア階層において最も低い階層にあり、少数の基本的な機能のみを実現するデバイスドライバの間で通信させる方式を用いたことで、ＯＳ間（クライアント-サーバ）通信に対応させるために改造を要する機能が最小限となるためである。
　本実施の形態では、サーバ-クライアント（ＯＳ－Ａ４０とＯＳ－Ｂ５０）間のやりとりにおいて、別途プロキシタスクを介することなく、デバイスドライバ間通信を使ったカーネルレベルの通信を用いる。また、ＯＳ－Ｂ５０（クライアント側）のデバイスドライバ５１は、ＯＳ－Ａ４０（サーバ側）のデバイスドライバ４１内の要求待ちリスト４６および処理中リスト４７に直接アクセスする。
　一般に、ソフトウェア階層においては、より低い階層の機能を組み合わせたり、あるいはそのバリエーションを増やして使いやすくした形で、より高い階層の機能を構成するため、より高い階層になるほど多くの種類のＡＰＩを備える傾向にある。逆に、最も低い層にあるデバイスドライバが備える機能は、一般に、オープン、クローズ、読み取り、書き込み、など少数の種類にとどまる。本実施の形態では、デバイスドライバという最も低い階層における通信を用いることで、デバイスドライバ間で通信させるための改造箇所を最小限にとどめることを可能にしている。
（第２の実施の形態）
　次に、本発明の第２の実施の形態について説明する。
　図２０を参照すると、第２の実施の形態は、デバイスインタフェース部（Ａ）４５に新たに判定部４５３を備えることを特徴としている。それ以外の部分は上述した第１の実施の形態と同様である。
　判定部４５３は、要求待ちリスト４６に蓄積されている１つ以上の処理要求構造体７０のインスタンスに対し、一定の規則に従って受理／却下の判定を下す機能、あるいは、一定の規則に従って次に処理すべきインスタンスを選定する機能を有する。
　デバイス設定部４５１には、判定部４５３が受理と判定した処理要求構造体７０のインスタンス、あるいは次に処理すべきと選定した処理要求構造体７０のインスタンスが渡される。
　具体的には、判定部４５３は、例えば、要求待ちリスト４６中の処理要求構造体７０のインスタンスのうち、あらかじめ指定されているＯＳ（例えばＯＳ－Ａ４０）以外のＯＳから要求されたインスタンスを破棄し、あるいは、あらかじめ指定されているＯＳ－タスクの組（例えばＯＳ－Ｂ５０上のタスク＃２とＯＳ－Ｂ５０上のタスク＃４等）から要求されたインスタンスを破棄するようにすることが可能である。
　このような判定部４５３を導入することにより、内部デバイスに対するＯＳ－タスクレベルでのアクセス制御を行うことができるという、新たな効果が得られる。
　また、他の具体例では、判定部４５３は、要求待ちリスト４６中の処理要求構造体７０のインスタンスを選択する際、直前の判定時に選択したインスタンスの要求元ＯＳとは異なる要求元ＯＳ値をもつインスタンスを優先して選択する、あるいは、あらかじめ指定されたＯＳ－タスクの組（例えばＯＳ－Ｂ上のタスク＃３）を要求元とするインスタンスが存在すれば必ずそれを選択するようにすることが可能である。
　このような判定部４５３を導入することにより、内部デバイスへアクセス要求を出す各ＯＳに対して公平なスケジューリングが可能になるという新たな効果が得られる。また、特定のＯＳ－タスクに対して優先的なデバイスアクセス権を与えることができるという、デバイスリソーススケジューリングに関する新たな効果が得られる。
（第３の実施の形態）
　次に、本発明の第３の実施の形態について説明する。
　図２１を参照すると、第３の実施の形態は、ＯＳ－Ａ４０内の要求待ちリスト４６が異なる目的の複数のリストから構成されていることを特徴とする。それ以外の部分は第１の実施の形態と同様である。
　この第３の実施の形態では、上記要求待ちリスト４６の内部の各リストは、各ＯＳに対応づけられることを特徴とする。
　すなわち、リスト４６１はＯＳ－Ａ４０に、リスト４６２はＯＳ－Ｂ５０に対応している。この例ではＯＳは２種類のみ示されているためリスト４６３は使用されない。
　そして、各ＯＳの要求解釈部（図２１の４４１、５４１）は、それぞれのＯＳに対応したリストに処理要求構造体７０のインスタンスを投入する。デバイス設定部４５１は、一定の規則、例えば各リストを順番に見て、処理要求構造体７０のインスタンスを取り出し、処理していく。タスクインタフェース部とデバイスインタフェース部は要求待ちリスト４６内の各リスト４６１～４６３毎に排他制御用のロック－アンロック操作を行う。
　上記第３の実施の形態によれば、要求待ちリストのロック－アンロックがＯＳ毎に実施されるため、本発明の第１の実施の形態に比べ、ロック獲得時に衝突が発生して待たされる可能性が低くなる。つまり、デバイスアクセスを行う際の性能オーバヘッドを低減する効果が得られる。この効果は、内部デバイスに対して細かなアクセス要求を高頻度に行う場合に特に顕著である。
　また、第３の実施の形態における変形例として、上記要求待ちリスト４６の内部の各リストが、異なる処理優先度で対応付けられるように構成することも可能である。
　すなわち、要求待ちリスト４６のリスト４６１を最高優先度、リスト４６２を普通の優先度、リスト４６３を最低優先度に対応付ける。これにより、例えば、デバイス設定部４５１は、リスト４６１を２回参照した後、リスト４６２を１回参照し、最初に見つかった処理要求構造体７０のインスタンスを取り出して処理するといった制御が可能となる。デバイス設定部４５１は、リスト４６１、４６２がいずれも空だった場合に限りリスト４６３を参照する。
　上記実施の形態の変形例によれば、デバイス設定部４５１は参照回数ベースの簡単な規則に従ってリスト４６１～４６３を参照することで内部デバイスへのアクセス優先度制御が行える。すなわち、内部デバイスに対するアクセス優先度制御を容易かつ低いＣＰＵオーバヘッドで実現できるという効果が得られる。
　なお、上記第２、第３の実施の形態を組み合わせて構成することも可能である。例えば、要求待ちリスト４６内に、ＯＳ毎に専用のリストを設けた上で、判定部４５３にて要求元タスクを調べて要求受理／却下判定を行う、といった構成により、性能オーバヘッドを抑えつつＯＳ－タスク毎のアクセス制御機能を搭載したＯＳ間デバイス共有機構を構築することができる。
（第４の実施の形態）
　次に、本発明の第４の実施の形態について説明する。
　図２２を参照すると、第４の実施の形態は、ＯＳ－Ａ４０にはタスクインタフェース部を備えず、デバイスインタフェース部のみを具備することを特徴とする。それ以外の部分は第１の実施の形態と同様である。
　上記実施の形態によれば、ＯＳ－Ａ４０では内部デバイスをアクセスするユーザタスクは一切稼動せず、ＯＳ－Ａ４０は内部デバイスの制御や管理に専念することになる。
　そのため本実施の形態は、内部デバイスのリアルタイム制御が行いやすいという効果をもたらす。この効果はＯＳ－Ａ４０としてリアルタイム処理（実時間処理）に適したＯＳ、例えばＴ－Ｋｅｒｎｅｌ等のリアルタイムＯＳを使用する場合に特に顕著である。
　更には、ＯＳ－Ａ４０としてリアルタイムＯＳを使用することに加え、ＯＳ－Ｂ５０としてＵＮＩＸやＷｉｎｄｏｗｓのようなアプリケーション向けの高度な機能を有するＯＳを使用すれば、デバイス制御のためのリアルタイム性能とアプリケーション向けの豊富な機能を両立したシステムを、１つのマルチコアプロセッサ上で実現することができる、という効果も実現できる。
　以上好ましい実施の形態と実施例をあげて本発明を説明したが、本発明は必ずしも、上記実施の形態及び実施例に限定されるものでなく、その技術的思想の範囲内において様々に変形して実施することができる。
　この出願は、２００８年３月１１日に出願された日本出願特願２００８－０６０８０４を基礎とする優先権を主張し、その開示の全てをここに取り込む。
　本発明は、マルチコアプロセッサ上で複数ＯＳを稼動させることで多様な動作要求を同時に満たす必要がある製品分野に適用可能である。例えば、無線ネットワーク処理とユーザ向けアプリケーション処理を行う携帯端末機器、放送受信と映像メディア処理とユーザインタフェース処理を行う情報家電機器、パワートレイン系とボデー系と情報メディア系の処理をあわせもつ車載機器、メカトロニクス制御と知能処理と対人インタフェース処理とを行うロボット搭載機器、などへの適用が想定される。

Claims (27)

  1. 　複数のＯＳが動作するマルチプロセッサシステムにおいて、
    　前記複数のＯＳが、ＯＳ間で共有するデバイスにアクセスするデバイスドライバを有し、
    　前記デバイスドライバが、
    　前記デバイスドライバの操作対象のデバイスとのアクセスを行うデバイスインタフェース部と、前記デバイスインタフェース部とＯＳカーネル層でのＯＳ間通信を行い、各ＯＳ上のタスクからのデバイスアクセス要求の受理とデバイスアクセス結果の前記タスクへの返却を行うタスクインタフェース部の少なくとも一方を有する
    　ことを特徴とするマルチプロセッサシステム。
  2. 　前記デバイスドライバが、前記デバイスインタフェース部と前記タスクインタフェース部を備える第１のデバイスドライバと、前記タスクインタフェース部を備える第２のデバイスドライバの何れかであることを特徴とする請求項１に記載のマルチプロセッサシステム。
  3. 　前記デバイスドライバが、前記デバイスインタフェース部を備える第１のドライバと、前記タスクインタフェース部を備える第２のデバイスドライバの何れかであることを特徴とする請求項１に記載のマルチプロセッサシステム。
  4. 　前記第２のデバイスドライバのタスクインタフェース部が、前記第１のデバイスドライバのデバイスインタフェース部に前記第２のデバイスドライバの識別情報を含むデバイスアクセス要求を送り、
    　前記第１のデバイスドライバのデバイスインタフェース部は、前記識別情報に基づいて、前記第２のデバイスドライバによる操作対象のデバイスアクセスを制御することを特徴とする請求項２に記載のマルチプロセッサシステム。
  5. 　前記デバイスドライバが、前記タスクインタフェース部と前記デバイスインタフェース部の双方からアクセス可能な要求待ちリストと処理中リストを備え、
    　前記要求待ちリストは、前記タスクインタフェース部から前記デバイスインタフェース部へのデバイスアクセス要求に関する情報を含む処理要求データを保持し、
    　前記処理中リストは、前記デバイスインタフェース部が操作対象のデバイスを用いて実行中のデバイスアクセス要求に対する前記処理要求データを保持し、
    　前記タスクインタフェース部は、ＯＳ上の要求元タスクからのデバイスアクセス要求に従って前記処理要求データを作成して前記要求待ちリストに追加したうえで、ＯＳ間通信によって前記デバイスインタフェース部に通知し、
    　前記デバイスインタフェース部は、前記要求待ちリストから前記処理要求データの１つを取り出して前記処理中リストに登録し、当該処理要求データの内容に従って操作対象のデバイスを設定して動作させ、
    　前記デバイスの動作完了後に、前記デバイスインタフェース部は、前記デバイスの処理結果を前記処理中リスト内の処理要求データに格納したうえで、ＯＳ間通信によって当該処理の要求元の前記タスクインタフェース部に通知し、
    　前記デバイスインタフェース部からの通知を受けた前記タスクインタフェース部は、前記処理中リストから前記処理要求データを取り出してその内容を参照し、要求元タスクに前記デバイスの処理結果を返却する
    　ことを特徴とする請求項１から請求項４の何れかに記載のマルチプロセッサシステム。
  6. 　前記ＯＳが、前記ＯＳ間通信を行うデバイスドライバ間通信部を備え、
    　前記デバイスドライバ間通信部は、被呼出ルーチンの登録部と、自ＯＳの登録済み被呼出ルーチンを呼び出す被呼出処理部と、通信先ＯＳの被呼出ルーチンに通知する呼出処理部とを有し、
    　前記呼出処理部は、被呼出ルーチンの識別子と、被呼出ルーチンに渡す引数とを、ＯＳ間共有メモリ領域とプロセッサ間割り込み機構を用いて通信先ＯＳの被呼出処理部に通知し、
    　通信先ＯＳは、プロセッサ間割り込みのハンドラの中で前記被呼出処理部を呼び出し、
    　前記被呼出処理部は、前記呼出処理部から通知された前記被呼出ルーチン識別子とその引数に基づいて、登録済み被呼出ルーチンのうちの１つを呼び出すことを特徴とする請求項１から請求項５の何れかに記載のマルチプロセッサシステム。
  7. 　前記デバイスインタフェース部は、前記タスクインタフェース部からのデバイスアクセス要求の優先度に基づいて、操作対象のデバイスへの複数のデバイスアクセス要求の順序を決定することを特徴とする請求項１から請求項６の何れかに記載のマルチプロセッサシステム。
  8. 　前記デバイスインタフェース部は、前記第２のデバイスドライバが動作するＯＳの識別情報と、各デバイスアクセスの要求元タスクの識別情報のいずれかあるいは両方に基づいて、当該操作対象のデバイスへのアクセス許可を判断する判定部を有することを特徴とする請求項４に記載のマルチプロセッサシステム。
  9. 　前記要求待ちリストが、前記複数のＯＳの各ＯＳ毎に対応付けられた複数のリストから構成されることを特徴とする請求項５に記載のマルチプロセッサシステム。
  10. 　前記要求待ちリストが、異なる優先度を設定した複数のリストから構成され、
    　前記デバイスインタフェース部は、前記要求待ちリストから前記処理要求データを取り出す際、前記リストの優先度に基づいて前記処理要求データの取り出しを行うことを特徴とする請求項５に記載のマルチプロセッサシステム。
  11. 　複数のＯＳが動作するマルチプロセッサシステムのＯＳ間で共有するデバイスにアクセスする前記ＯＳが備えるデバイスドライバであって、
    　前記デバイスドライバの操作対象のデバイスとのアクセスを行うデバイスインタフェース部と、前記デバイスインタフェース部とＯＳカーネル層でのＯＳ間通信を行い、各ＯＳ上のタスクからのデバイスアクセス要求の受理とデバイスアクセス結果の前記タスクへの返却を行うタスクインタフェース部の少なくとも一方を有することを特徴とするデバイスドライバ。
  12. 　前記デバイスドライバが、前記デバイスインタフェース部と前記タスクインタフェース部を備える第１のデバイスドライバと、前記タスクインタフェース部を備える第２のデバイスドライバの何れかであることを特徴とする請求項１１に記載のデバイスドライバ。
  13. 　前記デバイスドライバが、前記デバイスインタフェース部を備える第１のドライバと、前記タスクインタフェース部を備える第２のデバイスドライバの何れかであることを特徴とする請求項１１に記載のデバイスドライバ。
  14. 　前記第２のデバイスドライバのタスクインタフェース部が、前記第１のデバイスドライバのデバイスインタフェース部に前記第２のデバイスドライバの識別情報を含むデバイスアクセス要求を送り、
    　前記第１のデバイスドライバのデバイスインタフェース部は、前記識別情報に基づいて、前記第２のデバイスドライバによる操作対象のデバイスアクセスを制御することを特徴とする請求項１２に記載のデバイスドライバ。
  15. 　前記タスクインタフェース部と前記デバイスインタフェース部の双方からアクセス可能な要求待ちリストと処理中リストを備え、
    　前記要求待ちリストは、前記タスクインタフェース部から前記デバイスインタフェース部へのデバイスアクセス要求に関する情報を含む処理要求データを保持し、
    　前記処理中リストは、前記デバイスインタフェース部が操作対象のデバイスを用いて実行中のデバイスアクセス要求に対する前記処理要求データを保持し、
    　前記タスクインタフェース部は、ＯＳ上の要求元タスクからのデバイスアクセス要求に従って前記処理要求データを作成して前記要求待ちリストに追加したうえで、ＯＳ間通信によって前記デバイスインタフェース部に通知し、
    　前記デバイスインタフェース部は、前記要求待ちリストから前記処理要求データの１つを取り出して前記処理中リストに登録し、当該処理要求データの内容に従って操作対象のデバイスを設定して動作させ、
    　前記デバイスの動作完了後に、前記デバイスインタフェース部は、前記デバイスの処理結果を前記処理中リスト内の処理要求データに格納したうえで、ＯＳ間通信によって当該処理の要求元の前記タスクインタフェース部に通知し、
    　前記デバイスインタフェース部からの通知を受けた前記タスクインタフェース部は、前記処理中リストから前記処理要求データを取り出してその内容を参照し、要求元タスクに前記デバイスの処理結果を返却する
    　ことを特徴とする請求項１１から請求項１４の何れかに記載のデバイスドライバ。
  16. 　前記デバイスインタフェース部は、前記タスクインタフェース部からのデバイスアクセス要求の優先度に基づいて、操作対象のデバイスへの複数のデバイスアクセス要求の順序を決定することを特徴とする請求項１１から請求項１５の何れかに記載のデバイスドライバ。
  17. 　前記デバイスインタフェース部は、前記第２のデバイスドライバが動作するＯＳの識別情報と、各デバイスアクセスの要求元タスクの識別情報のいずれかあるいは両方に基づいて、当該操作対象のデバイスへのアクセス許可を判断する判定部を有することを特徴とする請求項１４に記載のデバイスドライバ。
  18. 　前記要求待ちリストが、前記複数のＯＳの各ＯＳ毎に対応付けられた複数のリストから構成されることを特徴とする請求項１５に記載のデバイスドライバ。
  19. 　前記要求待ちリストが、異なる優先度を設定した複数のリストから構成され、
    　前記デバイスインタフェース部は、前記要求待ちリストから前記処理要求データを取り出す際、前記リストの優先度に基づいて前記処理要求データの取り出しを行うことを特徴とする請求項１５に記載のデバイスドライバ。
  20. 　ＯＳ間で共有するデバイスにアクセスするデバイスドライバを有する複数のＯＳが動作するマルチプロセッサシステムのＯＳ間デバイス共有方法であって、
    　前記デバイスドライバが、デバイスインタフェース部と、タスクインタフェース部の少なくとも一方を有し、
    　前記タスクインタフェース部と前記デバイスインタフェース部とがＯＳカーネル層でのＯＳ間通信を行い、
    　前記デバイスインタフェース部が、前記デバイスドライバの操作対象のデバイスとのアクセスを行い、
    　前記タスクインタフェース部が、各ＯＳ上のタスクからのデバイスアクセス要求の受理とデバイスアクセス結果の前記タスクへの返却を行う
    ことを特徴とするＯＳ間デバイス共有方法。
  21. 　前記デバイスドライバが、前記デバイスインタフェース部と前記タスクインタフェース部を備える第１のデバイスドライバと、前記タスクインタフェース部を備える第２のデバイスドライバの何れかであることを特徴とする請求項２０に記載のＯＳ間デバイス共有方法。
  22. 　前記デバイスドライバが、前記デバイスインタフェース部を備える第１のドライバと、前記タスクインタフェース部を備える第２のデバイスドライバの何れかであることを特徴とする請求項２０に記載のＯＳ間デバイス共有方法。
  23. 　前記第２のデバイスドライバのタスクインタフェース部が、前記第１のデバイスドライバのデバイスインタフェース部に前記第２のデバイスドライバの識別情報を含むデバイスアクセス要求を送り、
    　前記第１のデバイスドライバのデバイスインタフェース部は、前記識別情報に基づいて、前記第２のデバイスドライバによる操作対象のデバイスアクセスを制御することを特徴とする請求項２１に記載のＯＳ間デバイス共有方法。
  24. 　前記デバイスドライバが、前記タスクインタフェース部と前記デバイスインタフェース部の双方からアクセス可能な要求待ちリストと処理中リストを備え、
    　前記要求待ちリストは、前記タスクインタフェース部から前記デバイスインタフェース部へのデバイスアクセス要求に関する情報を含む処理要求データを保持し、
    　前記処理中リストは、前記デバイスインタフェース部が操作対象のデバイスを用いて実行中のデバイスアクセス要求に対する前記処理要求データを保持し、
    　前記タスクインタフェース部は、ＯＳ上の要求元タスクからのデバイスアクセス要求に従って前記処理要求データを作成して前記要求待ちリストに追加したうえで、ＯＳ間通信によって前記デバイスインタフェース部に通知し、
    　前記デバイスインタフェース部は、前記要求待ちリストから前記処理要求データの１つを取り出して前記処理中リストに登録し、当該処理要求データの内容に従って操作対象のデバイスを設定して動作させ、
    　前記デバイスの動作完了後に、前記デバイスインタフェース部は、前記デバイスの処理結果を前記処理中リスト内の処理要求データに格納したうえで、ＯＳ間通信によって当該処理の要求元の前記タスクインタフェース部に通知し、
    　前記デバイスインタフェース部からの通知を受けた前記タスクインタフェース部は、前記処理中リストから前記処理要求データを取り出してその内容を参照し、要求元タスクに前記デバイスの処理結果を返却する
    　ことを特徴とする請求項２０から請求項２３の何れかに記載のＯＳ間デバイス共有方法。
  25. 　前記タスクインタフェースと前記デバイスインタフェースの間のＯＳ間通信が、あらかじめ被呼出ルーチンを登録しておき、
    　ＯＳ間通信時に、前記被呼出ルーチンの識別子と、被呼出ルーチンに渡す引数とをＯＳ間共有メモリ領域に格納した上で、マルチプロセッサシステムのプロセッサ間割り込み機構を用いて通信先ＯＳに通知し、
    　前記通信先ＯＳの割り込みハンドラは、前記プロセッサ間割り込みを受けて、ＯＳ間共有メモリ領域から被呼出ルーチンの識別子と被呼出ルーチンに渡す引数とを読み出し、それに基づいて登録済み被呼出ルーチンのうちの１つを呼び出すことを特徴とする請求項２０から請求項２４の何れかに記載のＯＳ間デバイス共有方法。
  26. 　前記デバイスインタフェース部は、前記第２のデバイスドライバが動作するＯＳの識別情報と、各デバイスアクセスの要求元タスクの識別情報のいずれかあるいは両方に基づいて、当該操作対象のデバイスへのアクセス許可を判断する判定部を有することを特徴とする請求項２３に記載のＯＳ間デバイス共有方法。
  27. 　前記要求待ちリストが、異なる優先度を設定した複数のリストから構成され、
    　前記デバイスインタフェース部は、前記要求待ちリストから前記処理要求データを取り出す際、前記リストの優先度に基づいて前記処理要求データの取り出しを行うことを特徴とする請求項２４に記載のＯＳ間デバイス共有方法。
PCT/JP2009/053236 2008-03-11 2009-02-24 マルチプロセッサシステム、マルチプロセッサシステムのｏｓ間デバイス共有方法 WO2009113381A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/919,636 US8661458B2 (en) 2008-03-11 2009-02-24 Multiprocessor system, and method for shared use of devices among operating systems of multiprocessor system
JP2010502756A JP5516398B2 (ja) 2008-03-11 2009-02-24 マルチプロセッサシステム、マルチプロセッサシステムのｏｓ間デバイス共有方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2008-060804 2008-03-11
JP2008060804 2008-03-11

Publications (1)

Publication Number Publication Date
WO2009113381A1 true WO2009113381A1 (ja) 2009-09-17

Family

ID=41065053

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/053236 WO2009113381A1 (ja) 2008-03-11 2009-02-24 マルチプロセッサシステム、マルチプロセッサシステムのｏｓ間デバイス共有方法

Country Status (3)

Country Link
US (1) US8661458B2 (ja)
JP (1) JP5516398B2 (ja)
WO (1) WO2009113381A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012079275A (ja) * 2010-10-06 2012-04-19 Yokogawa Electric Corp 外部デバイスアクセス装置およびコンピュータプログラム
WO2016017219A1 (ja) * 2014-07-31 2016-02-04 三菱電機株式会社 データ処理システム及びデータ処理方法及びプログラム
JP2018055285A (ja) * 2016-09-27 2018-04-05 富士ゼロックス株式会社 電子装置及び画像処理装置
JP2021157850A (ja) * 2014-09-19 2021-10-07 株式会社aLab デバイスプロキシ装置及びそれを含む計算機システム

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5505501B2 (ja) * 2010-06-22 2014-05-28 富士通株式会社 マルチコアプロセッサシステム、制御プログラム、および制御方法
WO2012015432A1 (en) * 2010-07-30 2012-02-02 Hewlett-Packard Development Company, L.P. Computer system and method for sharing computer memory
WO2012015431A1 (en) * 2010-07-30 2012-02-02 Hewlett-Packard Development Company, L.P. Computer system and method for sharing computer memory
WO2012137265A1 (en) * 2011-04-08 2012-10-11 Hitachi, Ltd. Computer, computer system, and data communication method
JP5842206B2 (ja) * 2012-01-27 2016-01-13 株式会社トプスシステムズ プロセッサ・コア、およびマルチコア・プロセッサ・システム
KR101956574B1 (ko) * 2012-02-24 2019-03-11 삼성전자주식회사 휴대용 단말기에서 호스트 디바이스의 운영 체제를 확인하기 위한 장치 및 방법
US9569362B2 (en) 2014-11-13 2017-02-14 Cavium, Inc. Programmable ordering and prefetch
US20160139806A1 (en) * 2014-11-13 2016-05-19 Cavium, Inc. Independent Ordering Of Independent Transactions
US10013385B2 (en) 2014-11-13 2018-07-03 Cavium, Inc. Programmable validation of transaction requests
JP6615726B2 (ja) * 2016-09-16 2019-12-04 株式会社東芝 情報処理装置、情報処理方法及びプログラム
CN113778705A (zh) * 2021-08-18 2021-12-10 北京自动化控制设备研究所 一种基于amp架构的多核通信方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007241562A (ja) * 2006-03-07 2007-09-20 Fujitsu Ltd デバイスドライバプログラムを記録したコンピュータ読取可能な記録媒体、記憶装置アクセス方法および記憶装置アクセスシステム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0272461A (ja) * 1988-09-07 1990-03-12 Hitachi Ltd 計算機システム
US5220653A (en) * 1990-10-26 1993-06-15 International Business Machines Corporation Scheduling input/output operations in multitasking systems
JPH1021203A (ja) * 1996-07-05 1998-01-23 Hitachi Ltd Ｉ／ｏ装置のアクセス方法およびそのためのマルチプロセッサシステム
US6085277A (en) * 1997-10-15 2000-07-04 International Business Machines Corporation Interrupt and message batching apparatus and method
US7647446B2 (en) * 2006-10-03 2010-01-12 Silex Technology, Inc. Networked isochronous USB communication

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007241562A (ja) * 2006-03-07 2007-09-20 Fujitsu Ltd デバイスドライバプログラムを記録したコンピュータ読取可能な記録媒体、記憶装置アクセス方法および記憶装置アクセスシステム

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
ADRIAN COCKCROFT: "Performance Tuning 27 Seikakuna Riyoritsu, Oto Jikan o Sanshutsu suru", SUNWORLD, vol. 10, no. 3, 1 March 2000 (2000-03-01), pages 106 - 110 *
AKIHIRO AMAGAI ET AL.: "Ethernet o Mochiita Dokigata Tsushin", IEICE TECHNICAL REPORT, vol. 104, no. 718, 7 March 2005 (2005-03-07), pages 1 - 6 *
HIROAKI TAKADA ET AL.: "Device Driver no Jisso", REAL-TIME OS TO KUMIKOMI GIJUTSU NO KISO, vol. 17, 1 July 2003 (2003-07-01), pages 141 - 168 *
HIROKAZU TAKAHASHI: "Kaso Machine Monitor Xen3.0 Kaidokushitsu", OSM, vol. 15, no. 4, 1 April 2006 (2006-04-01), pages 163 - 170 *
OSAMU KOSHIGOE: "Hardware Kasoka ni yoru Fukusu OS no Heiretsu Jikko", INTERFACE, vol. 33, no. 11, 1 November 2007 (2007-11-01), pages 94 - 102 *
YOSHIHIKO OGUCHI ET AL.: "Server Kasoka Gijutsu to Sono Saishin Doko", FUJITSU, vol. 58, no. 5, 10 September 2007 (2007-09-10), pages 426 - 430 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012079275A (ja) * 2010-10-06 2012-04-19 Yokogawa Electric Corp 外部デバイスアクセス装置およびコンピュータプログラム
WO2016017219A1 (ja) * 2014-07-31 2016-02-04 三菱電機株式会社 データ処理システム及びデータ処理方法及びプログラム
JP2021157850A (ja) * 2014-09-19 2021-10-07 株式会社aLab デバイスプロキシ装置及びそれを含む計算機システム
JP7093979B2 (ja) 2014-09-19 2022-07-01 株式会社aLab デバイスプロキシ装置及びそれを含む計算機システム
JP2018055285A (ja) * 2016-09-27 2018-04-05 富士ゼロックス株式会社 電子装置及び画像処理装置

Also Published As

Publication number Publication date
US8661458B2 (en) 2014-02-25
JP5516398B2 (ja) 2014-06-11
US20100325329A1 (en) 2010-12-23
JPWO2009113381A1 (ja) 2011-07-21

Similar Documents

Publication Publication Date Title
WO2009113381A1 (ja) マルチプロセッサシステム、マルチプロセッサシステムのｏｓ間デバイス共有方法
US9553944B2 (en) Application server platform for telecom-based applications using an actor container
US8181183B2 (en) Method, system and program products for managing thread pools of a computing environment to avoid deadlock situations
Pyarali et al. Evaluating and optimizing thread pool strategies for real-time CORBA
US20090158297A1 (en) System and method of dynamically loading and executing module devices using inter-core-communication channel in multicore system environment
JP2005505833A (ja) 多重発送プールを用いたアプリケーションサーバーのメッセージングのためのシステム
US8413163B2 (en) Program control device including per-timeslot switching of thread execution
US20070124523A1 (en) Heterogeneous multiprocessor system and OS configuration method thereof
US7765548B2 (en) System, method and medium for using and/or providing operating system information to acquire a hybrid user/operating system lock
US6418517B1 (en) Optimized function execution for a multiprocessor computer system
Karsten et al. User-level threading: Have your cake and eat it too
US7844782B2 (en) Data processing system with memory access
US10523746B2 (en) Coexistence of a synchronous architecture and an asynchronous architecture in a server
JP7346649B2 (ja) 同期制御システムおよび同期制御方法
Mueller On the Design and Implementation of DSM-Threads.
US20140165073A1 (en) Method and System for Hardware Assisted Semaphores
CN112749020A (zh) 一种物联网操作系统的微内核优化方法
JP2018536945A (ja) タスクをタイムベーススケジューリングする方法及び装置
JP2005327007A (ja) 組込みコンピュータ制御プログラム、そのプログラムを記録した記録媒体、及び組込みシステム
US7320044B1 (en) System, method, and computer program product for interrupt scheduling in processing communication
JP2010026575A (ja) スケジューリング方法およびスケジューリング装置並びにマルチプロセッサシステム
WO2003036465A2 (en) Efficient communication method and system
KR101635295B1 (ko) 휴대용 컴퓨팅 디바이스에서의 자원 요청들의 트랜잭션으로의 배칭 및 이러한 트랜잭션의 포킹
JP4833911B2 (ja) プロセッサユニットおよび情報処理方法
JP2000259436A (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: 09719650

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 12919636

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2010502756

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: 09719650

Country of ref document: EP

Kind code of ref document: A1