Dynamic thread status retrieval using inter-thread communication

• US 9,256,573 B2
• Filed: 02/14/2013
• Issued: 02/09/2016
• Est. Priority Date: 02/14/2013
• Status: Expired due to Fees

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Kuesel, Jamie R., Kupferschmidt, Mark G., Schardt, Paul E., Shearer, Robert A.
• Primary Examiner(s): Partridge, William B
• Assistant Examiner(s): NGUYEN, WILLIAM V
• Application Number:
  US13/767,133
• Publication Number:
  US 20140229709A1
• Time in Patent Office: 1,090 Days
• Field of Search: 712/31, 712/34, 712/35
• US Class Current: 1/1
• CPC Class Codes: G06F 11/30 Monitoring
• CPC Class Codes: G06F 11/3031 where the computing system component is a motherboard or an expansion card
• CPC Class Codes: G06F 11/3055 Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available error or fault processing without redundancy G06F11/0703; error detection or correction by redundancy in data representation G06F11/08; error detection or correction by redundancy in operation G06F11/14; error detection or correction by redundancy in hardware G06F11/16
• CPC Class Codes: G06F 11/3072 where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
• CPC Class Codes: G06F 11/3096 wherein the means or processing minimize the use of computing system or of computing system component resources, e.g. non-intrusive monitoring which minimizes the probe effect: sniffing, intercepting, indirectly deriving the monitored data from other directly available data
• CPC Class Codes: G06F 11/3433 for load management allocation of a server based on load conditions G06F9/505; load rebalancing G06F9/5083; redistributing the load in a network by a load balancer H04L67/1029
• CPC Class Codes: G06F 11/348 Circuit details, i.e. tracer hardware
• CPC Class Codes: G06F 13/362 with centralised access control
• CPC Class Codes: G06F 13/4068 Electrical coupling
• CPC Class Codes: G06F 15/76 Architectures of general purpose stored program computers with program plugboard G06F15/08; multicomputers G06F15/16
• CPC Class Codes: G06F 15/7825 Globally asynchronous, locally synchronous, e.g. network on chip
• CPC Class Codes: G06F 9/3009 Thread control instructions
• CPC Class Codes: G06F 9/5083 Techniques for rebalancing the load in a distributed system

Abstract

A circuit arrangement, method, and program product for dynamically providing a status of a hardware thread/hardware resource independent of the operation of the hardware thread/hardware resource using an inter-thread communication protocol. A master hardware thread may be configured to communicate status requests to associated slave hardware threads and/or hardware resources. Each slave hardware thread/hardware resource may be configured with hardware logic configured to automatically determine status information for the slave hardware thread/hardware resource and communicate a status response to the master hardware thread independent of the operation of the slave hardware thread/hardware resource.

Claims

1. A method for retrieving statuses for hardware threads in a network on a chip (NOC) processing system comprising a plurality of hardware threads configured in a plurality of interconnected integrated processor blocks, wherein each hardware thread includes an inbox and an outbox connected to a network of the NOC processing system with a direct inter-thread communication interface, the method comprising:

processing a software thread at a first hardware thread that causes the first hardware thread to perform the operations of a master hardware thread;

communicating a configuration message to the inboxes of a subset of the hardware threads from the master hardware thread that associates each hardware thread of the subset as a slave hardware thread for the master hardware thread, wherein the configuration message configures status logic associated with each slave hardware thread to automatically communicate a status response to the master hardware thread responsive to receiving a status request from the master hardware thread;

determining a plurality of slave hardware threads to retrieve a status from based at least in part on the processing of the software thread by the master hardware thread;

communicating a status request to the plurality of slave hardware threads from the master hardware thread;

receiving the status request at the inbox of each of the plurality of slave hardware threads;

in response to receiving the status request at the inbox of each of the plurality of slave hardware threads, determining a status for each of the plurality of slave hardware threads with status logic configured at each of the plurality of slave hardware threads and communicating a status response for each of the plurality of slave hardware threads based at least in part on the determined status;

receiving the status responses from the plurality of slave hardware threads at the inbox of the master hardware thread; and

storing status information to a memory of the NOC processing system for each of the plurality of slave hardware threads based at least in part on the status response received from each of the plurality of hardware threads.

2. A method for retrieving a status for a slave hardware thread in a network on a chip (NOC) processing system comprising a plurality of hardware threads configured in a plurality of interconnected integrated processor blocks, the method comprising:

receiving a status request for the slave hardware thread from a master hardware thread at an inbox associated with the slave hardware thread;

in response to receiving the status request at the inbox, determining a status associated with the slave hardware thread using status logic associated with the slave hardware thread, wherein the status logic is configured to determine the status associated with the slave hardware thread without interrupting processing of the slave hardware thread;

communicating a status response based on the status to the master hardware thread;

receiving a configuration message at the slave hardware thread from the master hardware thread;

processing the configuration message at the slave hardware thread to configure the status logic of the slave hardware thread to automatically communicate a status response responsive to receiving a status request to the master hardware thread;

communicating the status request from the master hardware thread; and

monitoring the receipt of the status response at the master hardware thread to determine whether the status response was received within a predefined amount of time from communicating the status request.

3. The method of claim 2, wherein determining a status associated with the slave hardware thread comprises:

analyzing a status register associated with the slave hardware thread with the status logic to determine the status.

4. The method of claim 2, further comprising:

determining the status associated with the slave hardware thread and communicating the status response are performed concurrent with processing a software thread with the slave hardware thread.

5. The method of claim 2, further comprising:

receiving the status response at the master hardware thread; and

storing status information for the slave hardware thread to memory based at least in part on the received status response.

6. The method of claim 5, further comprising:

prior to storing the status information for the slave hardware thread to memory, determining whether the status response is of a particular type by filtering the status response with a mask using thread status logic associated with the master hardware thread, wherein the status information is stored to memory responsive to determining that the status response is of the particular type.

7. The method of claim 2, further comprising:

receiving the status response at the master hardware thread; and

determining whether the status response is of a particular type.

8. The method of claim 7, further comprising:

in response to determining that the status response is of the particular type, communicating an interrupt message to the slave hardware thread.

9. The method of claim 7, wherein determining whether the status response is of a particular type comprises:

filtering the status response with thread status logic of the master hardware thread by with a mask.

10. The method of claim 2, further comprising:

communicating a notification from the master hardware thread responsive to not receiving the status response within the predefined amount of time.

11. The method of claim 2, wherein the plurality of hardware threads are connected to a network of the NOC processing system with a direct inter-thread communication interface.

12. A method for retrieving a status for a slave hardware thread in a network on a chip (NOC) processing system comprising a plurality of hardware threads configured in a plurality of interconnected integrated processor blocks, the method comprising:

receiving a status request for the slave hardware thread from a master hardware thread at an inbox associated with the slave hardware thread;

in response to receiving the status request at the inbox, determining a status associated with the slave hardware thread using status logic associated with the slave hardware thread, wherein the status logic is configured to determine the status associated with the slave hardware thread without interrupting processing of the slave hardware thread; and

communicating a status response based on the status to the master hardware thread;

receiving the status response at the master hardware thread;

storing status information for the slave hardware thread to memory based at least in part on the received status response;

prior to storing the status information for the slave hardware thread to memory, determining whether the status response is of a particular type by filtering the status response with a mask using thread status logic associated with the master hardware thread, wherein the status information is stored to memory responsive to determining that the status response is of the particular type;

receiving a configuration message at the slave hardware thread from the master hardware thread; and

processing the configuration message at the slave hardware thread to configure the status logic of the slave hardware thread to automatically communicate a status response responsive to receiving a status request to the master hardware thread.

13. The method of claim 12, wherein determining a status associated with the slave hardware thread comprises:

analyzing a status register associated with the slave hardware thread with the status logic to determine the status.

14. The method of claim 12, further comprising:

determining the status associated with the slave hardware thread and communicating the status response are performed concurrent with processing a software thread with the slave hardware thread.

15. The method of claim 12, further comprising:

in response to determining that the status response is of the particular type, communicating an interrupt message to the slave hardware thread.

16. The method of claim 12, further comprising:

communicating the status request from the master hardware thread; and

monitoring the receipt of the status response at the master hardware thread to determine whether the status response was received within a predefined amount of time from communicating the status request.

17. The method of claim 16, further comprising:

communicating a notification from the master hardware thread responsive to not receiving the status response within the predefined amount of time.

18. The method of claim 12, wherein the plurality of hardware threads are connected to a network of the NOC processing system with a direct inter-thread communication interface.