Preparing parallel tasks to use a synchronization register

CROSS-REFERENCED TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. patent application Ser. No. 13/314,477, filed Dec. 8, 2011. The aforementioned related patent application is herein incorporated by reference in its entirety.

BACKGROUND

A multi-nodal system is a type of computer system which completes computing jobs by means of multiple collaborative compute nodes which are connected together—e.g., a server or clustered computer system. These compute nodes may be located on the same physical system and be communicatively coupled using a bus or be remotely disposed and communicate via a communication network.

Using a multi-nodal system has many advantages. For example, the system, when working in a load-balance manner, can achieve a higher efficiency by dividing work and using multiple compute nodes. The multi-nodal system may also work in a master/slave manner. Once a master fails, a slave provides services to users as a substitute for the master, thereby exhibiting a high fault-tolerance.

Since the multi-nodal system normally comprises of large amounts of computing resources which work together collectively, each incoming job must be apportioned the correct amount of system resources. This process is referred to as job scheduling. In general, job scheduling includes mapping jobs to corresponding computing resources for execution based on a job's characteristics and scheduling policies. As part of this process, a job may be divided into one or more tasks (i.e., processes or threads). One or more of these tasks may then be executed on a compute node within the multi-nodal system. If multiple tasks are allocated to a single compute node, the multi-nodal system may use barrier synchronization to coordinate the activities of the various tasks.

Parallel processing, which distributes work among multiple concurrently executing tasks, may require synchronization between the tasks. One common method of providing this synchronization is via barrier synchronization. In general, barrier synchronization requires that each task in a group of communicating tasks needs to reach the same synchronization point (i.e., barrier) before any task within the group can proceed beyond that point. By definition, a barrier involves a group of tasks. Once a task enters the barrier, it waits for all other members of the same group to enter the barrier before it exits from the barrier.

When an application is processed in a parallel fashion, various jobs for the application are processed in parallel. Barrier synchronization provides a checkpoint mechanism that ensures that each job reaches a particular point before proceeding. This checkpoint mechanism is typically performed by the data stored in a special-purpose register—the barrier synchronization register (BSR).

SUMMARY

Embodiments of the invention provide a method, system and computer program product for synchronizing a plurality of tasks of a job. The method, system, and computer program product allocate a shared memory region for the plurality of tasks where the plurality of tasks is executed in parallel on a compute node. The method, system, and computer program product store, in the shared memory region, an indicator for discovering a register and retrieve the indicator from the shared memory region. The method, system, and computer program product discover the register using the retrieved indicator and, during a synchronization process, access the register to ensure that each of the plurality of tasks have completed.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above recited aspects are attained and can be understood in detail, a more particular description of embodiments of the invention, briefly summarized above, may be had by reference to the appended drawings.

It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.

<figref idref="DRAWINGS">FIGS. 1A-1B</figref> are block diagrams illustrating a networked system for performing client submitted jobs on a multi-nodal system, according to embodiments of the invention.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates a data structure in a shared memory region of a compute node in <figref idref="DRAWINGS">FIG. 1B</figref>, according to one embodiment of the invention.

<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart illustrating a technique for attaching a BSR to a plurality of tasks, according to one embodiment of the invention.

DETAILED DESCRIPTION

A job may be divided into multiple tasks that may execute in parallel on one or more compute nodes. The tasks executing on the same compute node may be coordinated using barrier synchronization. To perform barrier synchronization, the tasks use (or attach) to a BSR which is used to establish a common checkpoint for each of the tasks. Additionally, one of the tasks may be selected as a leader task while the other tasks are designated as follower tasks. The leader task may allocate a shared memory region for the group of tasks. The leader task may then use the shared memory region to publish a BSR ID, which discloses the location of the BSR, to the follower tasks. The follower tasks may retrieve the BSR ID from the shared memory region and attach to the BSR to enable barrier synchronization. Using the shared memory region, which is monitored by the follower tasks, advantageously avoids any task-to-task communication. This may reduce overhead and improve performance relative to a multi-nodal system that requires the leader task to transmit the BSR ID to each of the follower tasks, especially when a large number of tasks are executing on a particular compute node.

In the following, reference is made to embodiments of the invention. However, it should be understood that the invention is not limited to specific described embodiments. Instead, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the invention. Furthermore, although embodiments of the invention may achieve advantages over other possible solutions and/or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the invention. Thus, the following aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to “the invention” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

Embodiments of the invention may be provided to end users through a cloud computing infrastructure. Cloud computing generally refers to the provision of scalable computing resources as a service over a network. More formally, cloud computing may be defined as a computing capability that provides an abstraction between the computing resource and its underlying technical architecture (e.g., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. Thus, cloud computing allows a user to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) in “the cloud,” without regard for the underlying physical systems (or locations of those systems) used to provide the computing resources.

Typically, cloud computing resources are provided to a user on a pay-per-use basis, where users are charged only for the computing resources actually used (e.g. an amount of storage space consumed by a user or a number of virtualized systems instantiated by the user). A user can access any of the resources that reside in the cloud at any time, and from anywhere across the Internet. In context of the present invention, a user may access applications or related data available in the cloud. For example, the user may send a job to be executed by a multi-nodal system in the cloud that uses barrier synchronization. In such a case, the multi-nodal system could associate multiple tasks on the same compute node with a BSR using a shared memory region to publish the BSR ID. Doing so allows a user to access the multi-nodal system from any computing system attached to a network connected to the cloud (e.g., the Internet).

<figref idref="DRAWINGS">FIGS. 1A-1B</figref> are block diagrams illustrating a networked system for performing client submitted jobs on a multi-nodal system, according to embodiments of the invention. As shown, <figref idref="DRAWINGS">FIG. 1A</figref> is a block diagram illustrating a networked system for performing client submitted jobs on a multi-nodal system. In the depicted embodiment, the system <b>100</b> includes a client system <b>120</b> and a multi-nodal system <b>170</b>, connected by a network <b>150</b>. Generally, the client system <b>120</b> submits jobs over the network <b>150</b> to a job scheduler running on the multi-nodal system <b>170</b>. Nonetheless, any requesting entity may transmit jobs to the multi-nodal system <b>170</b>. For example, software applications (such as an application running on the client system <b>120</b>), operating systems, sub-systems, other multi-nodal systems <b>170</b> and, at the highest level, users may submit jobs. The term “job” denotes a set of commands for requesting resources from the multi-nodal system <b>170</b> and using these resources. Any object oriented programming language such as Java, Smalltalk, C++ or the like may be implemented to format the set of commands. Additionally, a multi-nodal system <b>170</b> may implement a unique programming language or provide a particular template. These jobs may be predefined (i.e., hard coded as part of an application) or may be generated in response to input (e.g., user input). Upon receiving the job, the multi-nodal system <b>170</b> executes the request and then returns the result.

<figref idref="DRAWINGS">FIG. 1B</figref> is a block diagram of a networked computer system configured to perform client submitted jobs on a multi-nodal system, according to one embodiment of the invention. As shown, the system <b>100</b> contains a client system <b>120</b> and a multi-nodal system <b>170</b>. The client system <b>120</b> contains a computer processor <b>122</b>, storage media <b>124</b>, memory <b>128</b> and a network interface <b>138</b>. The computer processor <b>122</b> may be any processor capable of performing the functions described herein. The client system <b>120</b> may connect to the network <b>150</b> using the network interface <b>138</b>. Furthermore, as will be understood by one of ordinary skill in the art, any computer system capable of performing the functions described herein may be used.

In the pictured embodiment, memory <b>128</b> contains an operating system <b>130</b> and a client application <b>132</b>. Although memory <b>128</b> is shown as a single entity, memory <b>128</b> may include one or more memory devices having blocks of memory associated with physical addresses, such as random access memory (RAM), read only memory (ROM), flash memory or other types of volatile and/or non-volatile memory. The client application <b>132</b> is generally capable of generating job requests. Once the client application <b>132</b> generates a job, the job may be submitted over the network <b>150</b> to a job scheduler for execution. The operating system <b>130</b> may be any operating system capable of performing the functions described herein.

The multi-nodal system <b>170</b> contains a network interface <b>172</b>, job scheduler <b>174</b>, and at least one compute node <b>180</b>. The network interface <b>172</b> connects to the network <b>150</b> and receives the job <b>176</b> transmitted from the client system <b>120</b>. The job scheduler <b>174</b> may use characteristic information about each compute node <b>180</b>, such as the number of processors <b>182</b> or amount of memory <b>184</b> contained on the node <b>180</b>, to determine what types of jobs should be allocated to the particular node <b>180</b>. The job scheduler <b>174</b> may divide a job <b>176</b> into a plurality of tasks which then may be assigned to the computer nodes <b>180</b>. This invention is not limited to any particular technique of dividing a received job into tasks that are then assigned to a compute node <b>180</b> for execution. The compute nodes <b>180</b> may be communicatively coupled by a bus or communication network. Moreover, although the job scheduler <b>174</b> is shown as being located outside a compute node <b>180</b>, in one embodiment the job scheduler <b>174</b> may be hosted by one of the compute nodes <b>180</b> of the multi-nodal system <b>170</b>.

The compute nodes <b>180</b> contain a computer processor <b>182</b> (CPU), memory <b>184</b>, and a barrier synchronization register <b>192</b> (BSR). CPU <b>182</b> is representative of a single CPU, multiple CPUs, a single CPU having multiple processing cores, and the like. The memory <b>184</b> is generally included to be representative of a random access memory (e.g., DRAM or Flash) as well as cache memory that may be associated with the CPU <b>182</b>. In one embodiment, the memory <b>184</b> contains a leader task <b>186</b> and one or more follower tasks <b>188</b>. The leader task <b>186</b> is elected to allocate the shared memory region <b>190</b> for use as a communication medium for the tasks <b>186</b>, <b>188</b>. The shared memory region <b>190</b> may be a logical partition of the memory <b>180</b>. The leader task <b>186</b> may also be assigned to monitor the shared memory region <b>190</b> to determine when all the follower tasks <b>188</b> have attached to the region <b>190</b>. The leader task <b>186</b> may also configure at least a portion of the BSR <b>192</b> to enable barrier synchronization for the tasks <b>186</b>, <b>188</b>.

In one embodiment, the BSR <b>192</b> is a special-purpose register built into the hardware of the multi-nodal system <b>170</b> to speed up barrier operations. The BSR <b>192</b> avoids relying completely on shared memory, and thus, evades the overhead of cache coherence. The BSR <b>192</b> may be faster than shared memory but, by the very nature of registers, may have a limited size.

In one embodiment, the BSR <b>192</b> is a distributed register that is accessible by all of the CPUs <b>182</b> on the compute node <b>180</b>. Logically, there is only one BSR <b>192</b> having a certain number of bytes. Physically, each CPU <b>182</b> has a local copy of the BSR <b>192</b>. All loads from the BSR <b>192</b> are local to the CPU <b>182</b> issuing the loads. All stores to the BSR <b>192</b> by any CPU <b>182</b> are broadcast to all other CPUs <b>182</b> of the compute nodes <b>180</b>. Firmware is responsible for the correctness of concurrent stores to the same BSR byte. All loads and stores are cache inhibited to avoid cache coherence cost, so as to provide fast synchronization by using the BSR <b>192</b>.

In one embodiment, the BSR <b>192</b> and barrier synchronization are used on POWER6® or POWER7® servers that implement POWER® instruction set architecture developed by IBM® (in contrast to x86 instruction set architecture). The BSR <b>192</b> enables one to write a parallel-processing application running on, for example, AIX® (a Unix based operating system) such that the application uses the BSR <b>192</b> to perform barrier synchronization.

In one embodiment, the BSR <b>192</b> may be divided into arrays which are assigned to partition profiles. In one embodiment, each BSR array may be 8 bytes long. The number of BSR arrays that are available on a compute node <b>180</b> depends on the type of processors used on the multi-nodal system <b>170</b>.

It is noted that while the present invention is described in terms of the use of the special-purpose BSR <b>192</b>, the methods herein are capable of employing any conveniently available allocatable region of memory. For example, a memory that offers faster access by the CPU <b>182</b> may be used as a BSR such as a level 1 or level 2 cache.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates a data structure in the shared memory region of a compute node in <figref idref="DRAWINGS">FIG. 1B</figref>, according to one embodiment of the invention. The data structure <b>200</b> includes a BSR state <b>202</b>, BSR ID <b>204</b>, bootstrap reference count <b>206</b>, and BSR setup reference count <b>208</b>. The data structure <b>200</b> may be generated by the leader task <b>186</b> and accessed by any of the tasks <b>186</b>, <b>188</b>. For example, the leader task <b>186</b> may change the BSR state <b>202</b>—e.g., “initializing”, “attached”, or “finished”—to communicate to the follower tasks <b>188</b> the current state of the BSR <b>192</b>. Additionally, each follower task <b>188</b> may retrieve from the data structure the BSR ID <b>204</b> to locate the BSR <b>192</b> or a relevant portion thereof. In general, the BSR ID <b>204</b> enables a leader or follower task <b>186</b>, <b>188</b> to attach to the BSR <b>194</b>. The bootstrap reference count <b>206</b> and BSR setup reference count <b>208</b> enable the tasks <b>186</b>, <b>188</b> to determine if all the associated tasks have attached to the shared memory region <b>190</b> and BSR <b>192</b>.

<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart illustrating a technique for associating a BSR to a plurality of tasks, according to one embodiment of the invention. At step <b>305</b> a leader task <b>186</b> is selected from among the tasks executing on the compute node <b>180</b> that are associated with the same job <b>176</b>. For example, if the job scheduler <b>174</b> assigns three tasks to the compute node <b>180</b> that are each processes of the same job <b>176</b>, one of these tasks is assigned as the leader task <b>186</b>. This assignment may be made by the job scheduler <b>174</b> when the tasks are created or after the tasks have been assigned to the computer node <b>180</b>. Further, a task may be selected as the leader task <b>186</b> if it was the first task allocated to the compute node <b>190</b>, by random selection, or by an estimated time of completing the task. This invention is not limited by any particular method for selecting the leader task, and any known method may be used.

At step <b>310</b>, the leader task <b>186</b> allocates a portion of the memory <b>184</b> as the shared memory region <b>190</b> and may create the data structure <b>200</b> shown in <figref idref="DRAWINGS">FIG. 2</figref>. In one embodiment, the leader task <b>186</b> may use one or more attributes that are in common to all the tasks of a particular job <b>175</b> to allocate the shared memory region <b>190</b>. For example, each task associated may be associated with a key (i.e., attribute) which may be used to allocate and locate the shared memory region <b>190</b>. A leader task <b>186</b> may use the key to allocate the shared memory region <b>190</b>—e.g., use the key to generate a name or storage location of the region <b>190</b>. A follower task <b>188</b> may use the same key to derive the correct name or storage location of the shared memory region <b>190</b>. In one embodiment, the job scheduler <b>174</b> may provide the common attribute to each task when the tasks are assigned to a compute node.

At step <b>315</b>, the leader task <b>186</b> may set the BSR state <b>202</b> to “initializing”. During this state, the leader task <b>186</b> waits for all the follower tasks <b>188</b> of the compute node <b>190</b> to locate and attach to the shared memory region <b>190</b>. As each follower task <b>188</b> uses the common attribute to locate the shared memory region <b>190</b>, it increments the bootstrap reference count <b>206</b> which enables the tasks to maintain a record of how many of the tasks on the compute node <b>180</b> have attached to the shared memory region <b>190</b>. For example, once the leader task <b>186</b> allocates the shared memory region <b>190</b>, it increments the bootstrap reference count <b>206</b>. Similarly, after each follower task <b>188</b> locates or attaches to the shared memory region <b>190</b> it atomically increments the count <b>206</b>—i.e., only one follower task <b>188</b> is permitted to increment the bootstrap reference count <b>206</b> at a time.

In one embodiment, as the tasks are generated and assigned to the compute node <b>180</b>, at least one of the tasks includes a record of how many tasks were assigned by the job scheduler <b>174</b> to the compute node <b>180</b>. For example, if the job scheduler <b>174</b> assigned four tasks to the compute node <b>180</b> for a particular job <b>176</b>, each of these tasks may know that there are four total tasks executing on the compute node <b>180</b>.

At step <b>320</b>, the task that knows the total number of tasks assigned to the compute node <b>180</b> determines if all the tasks have attached to the shared memory region <b>190</b>. For example, if the leader task <b>186</b> knows that there are four total tasks assigned to the node <b>180</b>, it may monitor the bootstrap reference count <b>206</b> to determine if all the tasks have attached to the shared memory region <b>190</b>—i.e., a count of four. If so, at step <b>325</b>, the leader task <b>186</b> may automatically configure the BSR <b>192</b> without receiving a command from any application assigned to monitor the parallel-processing of the tasks. That is, the bootstrap reference count <b>206</b> allows “bootstrapping” the configuration of the BSR <b>192</b> without further command from, for example, the job scheduler <b>174</b>.

In one embodiment, configuring the BSR <b>192</b> may require allocating only a portion of the BSR <b>192</b> for use by the leader and follower tasks <b>186</b>, <b>188</b>. For example, different jobs and tasks may be executing on the compute node <b>180</b> which may simultaneously use the BSR <b>192</b> to perform barrier synchronization. In this case, the leader task <b>186</b> may allocate only a portion of the BSR <b>192</b> (or one or more BSR array slots) for use by the tasks <b>186</b>, <b>188</b>. After configuring the BSR <b>192</b>, the leader task <b>186</b> may publish the BSR ID <b>204</b> in the data structure <b>200</b>. The BSR ID <b>204</b> permits the follower tasks <b>188</b> to locate and attach to the BSR <b>192</b> or to a relevant portion thereof.

In one embodiment, the follower tasks <b>188</b> may not know when the BSR ID <b>204</b> is updated to identify the correct location of the BSR <b>192</b>. Accordingly, at step <b>330</b>, the leader task <b>186</b> may update the BSR state <b>202</b> to “attached”. This state indicates to the follower tasks <b>188</b> to use the BSR ID <b>204</b> to locate and attach to the BSR <b>192</b>. As the leader task <b>186</b> and each follower task <b>188</b> attaches to the BSR <b>192</b>, they atomically increment the BSR setup reference count <b>208</b>.

At step <b>335</b>, a task that knows the total number of tasks for a particular job assigned to the compute node <b>180</b> monitors the BSR setup reference count <b>208</b> to determine if the count matches the total number of tasks. If so, then the leader task <b>186</b> may change the BSR state <b>202</b> to “finished” at step <b>340</b> to inform each follower task <b>188</b> that the BSR <b>192</b> has properly been configured. Accordingly, the leader and follower tasks <b>186</b>, <b>188</b> consider the setup of the BSR <b>192</b> memory region as complete.

If at step <b>320</b> or <b>335</b> the leader task <b>186</b> determines that bootstrap reference count <b>206</b> or the BSR setup reference count <b>208</b> does not reflect the total number of assigned tasks, the leader task <b>186</b> may change the BSR state <b>202</b> to “failed”. For example, the leader task <b>186</b> may monitor these counts <b>206</b>, <b>208</b> for a predetermined period of time. Once that time has been met and all the follower tasks <b>188</b> have not attached, the leader task <b>186</b> may change the BSR state <b>202</b>. In one embodiment, the predetermined period of time may be set by the job scheduler <b>174</b> and may vary based on the number of tasks that are assigned to the compute node <b>180</b> for that job <b>176</b>. For example, the greater the number of tasks, the greater the length of the time limit.

At step <b>350</b>, the leader task <b>186</b> may deallocate the shared memory region <b>190</b> and the portion BSR <b>192</b> (if any) and report the failure to the job scheduler <b>174</b>. Further, the follower tasks <b>188</b> may detach from both the shared memory region <b>190</b> and the BSR <b>192</b>.

CONCLUSION

Using a shared memory region enables a leader task to publish a BSR ID to a group of follower tasks without using task-to-task messages to communicate the BSR ID to all the tasks. Each follower task can monitor the shared memory region and, when determining the BSR has been configured, use the BSR ID to attach to the BSR. In this manner, overhead may be reduced and performance increased relative to multi-nodal systems that require the leader task to transmit the BSR ID to each of the follower tasks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.