US20120291034A1 - Techniques for executing threads in a computing environment - Google Patents

Techniques for executing threads in a computing environment Download PDF

Info

Publication number
US20120291034A1
US20120291034A1 US13/107,896 US201113107896A US2012291034A1 US 20120291034 A1 US20120291034 A1 US 20120291034A1 US 201113107896 A US201113107896 A US 201113107896A US 2012291034 A1 US2012291034 A1 US 2012291034A1
Authority
US
United States
Prior art keywords
thread
message
associated
response
wake
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/107,896
Inventor
Dayavanti G. Kamath
Nirapada Ghosh
Dar-Ren Leu
Nilanjan Mukherjee
Vijoy Pandey
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
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 International Business Machines Corp filed Critical International Business Machines Corp
Priority to US13/107,896 priority Critical patent/US20120291034A1/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GHOSH, NIRAPADA, KAMATH, DAYAVANTI G., LEU, DAR-REN, MUKHERJEE, NILANJAN, PANDEY, VIJOY A.
Publication of US20120291034A1 publication Critical patent/US20120291034A1/en
Application status is Abandoned legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/52Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/48Indexing scheme relating to G06F9/48
    • G06F2209/486Scheduler internals

Abstract

A technique for executing normally interruptible threads of a process in a non-preemptive manner includes in response to a first entry associated with a first message for a first thread reaching a head of a run queue, receiving, by the first thread, a first wake-up signal. In response to receiving the wake-up signal, the first thread waits for a global lock. In response to the first thread receiving the global lock, the first thread retrieves the first message from an associated message queue and processes the retrieved first message. In response to completing the processing of the first message, the first thread transmits a second wake-up signal to a second thread whose associated entry is next in the run queue. Finally, following the transmitting of the second wake-up signal, the first thread releases the global lock.

Description

    BACKGROUND OF THE INVENTION
  • 1. Technical Field
  • The present invention relates in general to threads and, in particular to, techniques for executing threads in a computing environment.
  • 2. Description of the Related Art
  • The term ‘utility computing’ has been used to refer to a computational model in which processing, storage and network resources, software, and data are accessible to client computer systems and other client devices (e.g., mobile phones or media players) on demand, much like familiar residential utility services, such as water and electricity. In some implementations, the specific computational resources (e.g., servers, storage drives, etc.) allocated for access and use by client devices are specified by service agreements between the utility computing provider and its customers. In other implementations, commonly referred to as “cloud computing,” details of the underlying information technology (IT) infrastructure are transparent to the utility computing customers.
  • Cloud computing is facilitated by ease-of-access to remote computing websites (e.g., via the Internet or a private corporate network) and frequently takes the form of web-based resources, tools, or applications that a cloud consumer can access and use through a web browser, as if the resources, tools, or applications were a local program installed on a computer system of the cloud consumer. Commercial cloud implementations are generally expected to meet quality of service (QoS) requirements of cloud consumers, which may be specified in service level agreements (SLAs). In a typical cloud implementation, cloud consumers consume computational resources as a service and pay only for the resources used.
  • Adoption of utility computing has been facilitated by the widespread utilization of virtualization, which is the creation of virtual (rather than actual) versions of computing resources, e.g., an operating system, a server, a storage device, network resources, etc. For example, a virtual machine (VM), also referred to as a logical partition (LPAR), is a software implementation of a physical machine (e.g., a computer system) that executes instructions like a physical machine. VMs can be categorized as system VMs or process VMs. A system VM provides a complete system platform that supports the execution of a complete operating system (OS), such as Windows, Linux, AIX, Android, etc., as well as its associated applications. A process VM, on the other hand, is usually designed to run a single program and support a single process. In either case, any application software running on the VM is limited to the resources and abstractions provided by that VM. Consequently, the actual resources provided by a common IT infrastructure can be efficiently managed and utilized through the deployment of multiple VMs, possibly associated with multiple different utility computing customers.
  • The virtualization of actual IT resources and management of VMs is typically provided by software referred to as a VM monitor (VMM) or hypervisor. In various implementations, a VMM may run on bare hardware (Type 1 or native VMM) or on top of an operating system (Type 2 or hosted VMM).
  • In a typical virtualized computing environment, VMs can communicate with each other and with physical entities in the IT infrastructure of the utility computing environment utilizing conventional networking protocols. As is known in the art, conventional networking protocols are commonly premised on the well known seven layer Open Systems Interconnection (OSI) model, which includes (in ascending order) physical, data link, network, transport, session, presentation, and application layers. VMs are enabled to communicate with other network entities as if the VMs were physical network elements through the substitution of a virtual network connection for the conventional physical layer connection.
  • The UNIX® operating system (OS) was designed to be a portable, multi-tasking, and multi-user OS. UNIX is characterized by: the use of plain text for storing data; a hierarchical file system; treating devices and certain types of inter-process communications (IPCs) as files; and the use of a large number of software tools. UNIX includes various utilities along with a master control program, i.e., the UNIX kernel. The UNIX kernel provides services to start and stop programs, handles the file system and other common low-level tasks that most programs share, and schedules access to hardware to avoid conflicts if multiple programs try to access the same resource or device simultaneously. Because of the acknowledged security, portability and functionality of UNIX, a large number of similar operating system have been developed, including Linux™, Minix™, Mac OS™, FreeBSD™, NetBSD™, OpenBSD™, AIX™, Solaris™, and HP/UX™. All of these operating systems, together with UNIX, are referred to herein as “Unix-like” OSs. Unix-like OSs can be installed on a wide variety of hardware, e.g., mobile phones, tablet computers, video game consoles, networking gear, mainframes, and supercomputers.
  • In computer science, a thread of execution (thread) is usually the smallest unit of processing that can be scheduled by an OS. A thread generally results from a fork of a computer program into two or more concurrently running tasks. The implementation of threads and processes may differ between OSs, but in most cases a thread is included within a process. Multiple threads can exist within the same process and share resources (e.g., memory), while different processes do not share the same resources. On a single processor system, multi-threading is implemented through time-division multiplexing (i.e., a processor switches between executing different threads). On a multi-processor or multi-core system, multiple threads may run at the same time on different processors or processor cores. Many modern OSs directly support both time-sliced and multi-processor threading with a process scheduler. The kernel of an OS allows programmers to manipulate threads via a system call interface.
  • Portable operating system interface for UNIX (POSIX) is the name of a family of related standards that define an application programming interface (API), along with shell and utilities interfaces, for software compatible with Unix-like OSs. POSIX threads (pthreads) refer to threads that are compliant with the POSIX standard for threads (i.e., POSIX.1c (IEEE 1003.1c-1995), which defines an API for creating and manipulating threads). Implementations of the POSIX API are available on many Unix-like POSIX-conformant OSs, e.g., FreeBSD™, NetBSD™, GNU/Linux™, Mac OS X™, and Solaris™.
  • SUMMARY OF THE INVENTION
  • A technique for executing normally interruptible threads of a process in a non-preemptive manner includes in response to a first entry associated with a first message for a first thread reaching a head of a run queue, receiving, by the first thread, a first wake-up signal. In response to receiving the wake-up signal, the first thread waits for a global lock. In response to the first thread receiving the global lock, the first thread retrieves the first message from an associated message queue and processes the retrieved first message. In response to completing the processing of the first message, the first thread transmits a second wake-up signal to a second thread whose associated entry is next in the run queue. Finally, following the transmitting of the second wake-up signal, the first thread releases the global lock.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a high level block diagram of a data processing environment in accordance with one embodiment;
  • FIG. 2 depicts the layering of virtual and physical resources in the exemplary data processing environment of FIG. 1 in accordance with one embodiment;
  • FIG. 3 is a high level block diagram of a data processing system in accordance with one embodiment;
  • FIG. 4 is a high level block diagram of a portion of a data processing environment employing physical network switches configured in accordance with one embodiment;
  • FIG. 5 is a block diagram of a relevant portion of a physical network switch configured in accordance with one embodiment;
  • FIG. 6 is a high level logical flowchart of an exemplary method of operating an operating system (OS) scheduler of a physical network switch configured in accordance with one embodiment;
  • FIG. 7 is a high level logical flowchart of an exemplary method of performing inter-thread communication in a physical network switch configured in accordance with one embodiment; and
  • FIG. 8 is a high level logical flowchart of an exemplary method of executing threads in a physical network switch configured in accordance with one embodiment.
  • DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENT
  • According to the present disclosure, techniques are disclosed that facilitate running legacy software (i.e., a legacy bare metal OS) on top of a Unix-like OS, such as Linux. In various cases, running legacy software on top of a Unix-like OS enables reuse of certain legacy code, while improving scalability through access to a multi-core, multi-processor OS. While the discussion herein is directed to running legacy software on top of a Unix-like OS in a physical network switch that is implemented in a virtualized computing environment, it is contemplated that the techniques disclosed herein are broadly applicable to virtualized and non-virtualized computing environments and may be implemented in devices other than physical network switches. As used herein, a ‘stem thread’ refers to a legacy proprietary user-space thread that ran non-preemptively (i.e., that was uninterruptible) in a serialized manner in an order that messages were posted to a stem message queue (provided by the legacy software). The legacy software also implemented a stem dispatcher that was in charge of processing stem messages and scheduling stem threads. As used herein, the term ‘pthreads’, by itself, refers to Unix-like OS threads that run preemptively (i.e., interruptible) in no particular order within a priority class and that are normally completely controlled by an OS scheduler of a Unix-like OS. As is also used herein, a ‘stem pthread’ is a stem thread that has been converted to be similar to a pthread.
  • To ensure application code compatibility, restrictions are enforced on stem pthreads that differentiate stem pthreads from pthreads. One restriction serializes stem pthreads by employing a global mutual exclusion (mutex) that functions as a global lock to cause stem pthreads to run like stem threads (i.e., as uninterruptible threads). That is, only one stem pthread (i.e., the stem pthread with the global lock) can process a message at any given time. Another restriction causes stem pthreads to self-regulate by waiting (after being woke-up) for a global lock before performing message processing. To ensure that stem pthreads get scheduled in the same order as the messages are posted (to emulate the legacy software), a single run queue is maintained for all stem pthreads with messages to be processed. In various embodiments, all stem pthreads sleep while waiting for an associated message to reach a head of the run queue. In one or more embodiments, each stem pthread is configured to: run a continuous entry function that waits for a global lock; process one message in an associated message queue upon receiving the global lock; and then relinquish the global lock.
  • Before an active stem pthread goes back to sleep, the active stem pthread is configured to check the run queue and wake-up a stem pthread associated with a next entry in the run queue. This ensures that when the global lock is released by the active stem pthread, a stem pthread associated with a next entry in the run queue retrieves the global lock and begins executing an associated message processing function. Before an active stem pthread goes back to sleep, the active stem pthread is also configured to check an associated message queue and if the active stem pthread has additional messages to process, the active stem pthread queues an entry for one of the additional messages to the end of the run queue. When the additional message reaches the head of the run queue at a subsequent time, the stem pthread receives a wake-up signal and begins processing the additional message. For example, an entry in the run queue may correspond to a global identifier (ID) for a given stem pthread.
  • In contrast to the legacy software discussed above, software configured according to the present disclosure does not implement stem thread dispatcher code, as the Unix-like OS scheduler performs basic thread scheduling. The Unix-like OS scheduler maintains various background information on scheduled threads and an API layer (that executes on top of the Unix-like OS scheduler) maintains housekeeping information (e.g., whether a scheduled thread is a stem pthread or a pthread). According to the present disclosure, each thread (i.e., stem pthreads and pthreads) includes code that is configured to process associated message queues and messages. Any new modules written for the system may employ pthreads that are not (usually) restricted. For example, if pthreads implement their own locks, the pthreads can run independently on the parts of the code that are not shared with common data structures. If a pthread needs to access any data structure that is shared with a stem pthread, the pthread can be temporarily serialized by placing the pthread on the run queue and waiting for the global lock when the pthread is woken-up.
  • Communication between pthreads and stem pthreads may be implemented in a number of different ways. For example, inter-thread communication may be achieved on the send side using stem messages (which include a command and a message), an OS interface (OSIX) event send call (which includes a command and a message pointer for a thread with a single associated message queue), or an OSIX event queue send call (which includes a command and a message pointer for a thread with multiple associated message queues). In various embodiments, a sending thread is configured to store a message for a receiving thread in a message queue associated with the receiving thread. In determining a message queue for a receiving thread, a sending thread may, for example, employ an API to retrieve a global thread ID for the receiving thread (which also indicates, for example, a location for a message queue for the receiving thread) from a data structure (e.g., a table, which may be maintained by an API layer that executes on top of the Unix-like OS scheduler).
  • In one or more embodiments, stem pthreads receive messages (i.e., stem messages or OSIX messages) from a wrapper routine, which dequeues the message from an associated message queue of the stem pthread and calls an entry routine of the stem pthread with the message as a parameter. The wrapper routine may, for example, be implemented as a Unix-like OS module. In one or more embodiments, pthreads wait on blocking condition variables when receiving messages. When a blocking condition variable is signaled, a pthread reads an event and retrieves a message pointer to an associated message queue. In various embodiments, the pthreads use an OSIX event receive call or an OSIX event queue receive call to retrieve a message pointer. In order to facilitate transparent thread communication from an application layer perspective, applications may be configured to send stem messages or OSIX messages to any kind of receiver (i.e., stem pthreads or pthreads). When a stem message is destined for a pthread, the stem message is converted to an OSIX event condition and an OSIX queue message by a stem send routine (which may be implemented as a Unix-like OS module). When an OSIX message is destined for a stem pthread, the OSIX message is converted to a stem message by an OSIX send routine (which may be implemented as a Unix-like OS module). This ensures that both stem pthreads and pthreads can maintain their receive processing in an unmodified state. Since the mechanism for message conversion is hidden, with respect to application code, application code does not require modification.
  • With reference now to the figures and with particular reference to FIG. 1, there is illustrated a high level block diagram of an exemplary data processing environment 100 in accordance within one embodiment of the present disclosure. As shown, data processing environment 100, which in the depicted embodiment is a cloud computing environment, includes a collection of computing resources commonly referred to as a cloud 102. Computing resources within cloud 102 are interconnected for communication and may be grouped (not shown) physically or virtually, in one or more networks, such as private, community, public, or hybrid clouds or a combination thereof. In this manner, data processing environment 100 can offer infrastructure, platforms and/or software as services accessible to client devices 110, such as personal (e.g., desktop, laptop, netbook, tablet, or handheld) computers 110 a, smart phones 110 b, server computer systems 110 c and consumer electronics 110 d, such as media players (e.g., set top boxes, digital versatile disk (DVD) players, or digital video recorders (DVRs)). It should be understood that the types of client devices 110 shown in FIG. 1 are illustrative only and that client devices 110 can be any type of electronic device capable of communicating with and accessing services of computing resources via a packet network.
  • FIG. 2 is a layer diagram depicting the virtual and physical resources residing in collection of cloud 102 of FIG. 1 in accordance with one embodiment. It should be understood that the computing resources, layers, and functions shown in FIG. 2 are intended to be illustrative only and embodiments of the claimed inventions are not limited thereto.
  • As depicted, cloud 102 includes a physical layer 200, a virtualization layer 202, a management layer 204, and a workloads layer 206. Physical layer 200 includes various physical hardware and software components that can be used to instantiate virtual entities for use by the cloud service provider and its customers. As an example, the hardware components may include mainframes (e.g., IBM® zSeries® systems), reduced instruction set computer (RISC) architecture servers (e.g., IBM pSeries® systems), IBM xSeries® systems, IBM BladeCenter® systems, storage devices (e.g., flash drives, magnetic drives, optical drives, tape drives, etc.), physical networks, and networking components (e.g., routers, switches, etc.). The software components may include operating system software (e.g., AIX, Windows, Linux, etc.), network application server software (e.g., IBM WebSphere® application server software, which includes web server software), and database software (e.g., IBM DB2® database software). IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere, and DB2 are trademarks of International Business Machines Corporation registered in many jurisdictions worldwide.
  • The computing resources residing in physical layer 200 of cloud 102 are virtualized and managed by one or more virtual machine monitors (VMMs) or hypervisors. The VMMs present a virtualization layer 202 including virtual entities (e.g., virtual servers, virtual storage, virtual networks (including virtual private networks)), virtual applications, and virtual clients. As discussed previously, these virtual entities, which are abstractions of the underlying resources in physical layer 200, may be accessed by client devices 110 of cloud consumers on-demand.
  • The VMM(s) also support a management layer 204 that implements various management functions for the cloud 102. These management functions can be directly implemented by the VMM(s) and/or one or more management or service VMs running on the VMM(s) and may provide functions such as resource provisioning, metering and pricing, security, user portal services, service level management, and SLA planning and fulfillment. The resource provisioning function provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. The metering and pricing function provides cost tracking (as resources are provisioned and utilized within the cloud computing environment) and billing or invoicing for consumption of the utilized resources. As one example, the utilized resources may include application software licenses. The security function provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. The user portal function provides access to the cloud computing environment for consumers and system administrators. The service level management function provides cloud computing resource allocation and management such that required service levels are met. For example, the security function or service level management function may be configured to limit deployment/migration of a virtual machine (VM) image to geographical location indicated to be acceptable to a cloud consumer. The service level agreement (SLA) planning and fulfillment function provides pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA.
  • Workloads layer 206, which may be implemented by one or more consumer VMs, provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from workloads layer 206 include: mapping and navigation; software development and lifecycle management; virtual classroom education delivery; data analytics processing; and transaction processing.
  • With reference now to FIG. 3, there is illustrated a high level block diagram of an exemplary data processing system 300 that can be utilized to implement a physical host computing platform in physical layer 200 of FIG. 2 or a client device 110 of FIG. 1. In the illustrated exemplary embodiment, data processing system 300 includes one or more network interfaces 304 that permit data processing system 300 to communicate with one or more computing resources in cloud 102 via cabling and/or one or more wired or wireless, public or private, local or wide area networks (including the Internet). Data processing system 300 additionally includes one or more processors 302 that process data and program code, for example, to manage, access and manipulate data or software in data processing environment 100. Data processing system 300 also includes input/output (I/O) devices 306, such as ports, displays, and attached devices, etc., which receive inputs and provide outputs of the processing performed by data processing system 300 and/or other resource(s) in data processing environment 100. Finally, data processing system 300 includes data storage 310, which may include one or more volatile or non-volatile storage devices, including memories, solid state drives, optical or magnetic disk drives, tape drives, etc. Data storage 310 may store, for example, software within physical layer 200 and/or software, such as a web browser, that facilitates access to workloads layer 206 and/or management layer 204.
  • Referring now to FIG. 4, there is depicted a high level block diagram of a portion of a data processing environment 400 employing physical network switches configured in accordance with one or more embodiments of the present disclosure. For example, data processing environment 400 can implement a portion of cloud 102 depicted in FIG. 1.
  • In the depicted embodiment, data processing environment 400 includes an Internet protocol (IP) network 402 including a plurality of network segments 404 a, 404 b, each of which is coupled to a respective one of physical network switches 406 a, 406 b. As is depicted, each of physical network switches 406 a, 406 b includes a respective data structure (e.g., a respective forwarding table (F)) 407 a, 407 b by which physical network switches 406 a, 406 b forward incoming data packets toward the packets' destinations based upon, for example, OSI Layer 2 (e.g., media access control (MAC)) addresses contained in the packets. As is discussed in further detail with reference to FIG. 8, physical network switches 406 a, 406 b are configured to run legacy software on top of a Unix-like OS. As noted above, legacy stem threads are converted to stem pthreads and new modules are written to implement pthreads. Physical hosts 410 a, 410 b are coupled to network segment 404 a and physical host 410 c is coupled to network segment 404 b. Each of physical hosts 410 a-410 c can be implemented, for example, utilizing a data processing system 300 as depicted in FIG. 3.
  • Each of physical hosts 410 a-410 c executes a respective one of VMM 412 a-412 c, which virtualizes and manages the resources of its respective physical host 410, for example, under the direction of a human and/or automated cloud administrator at a management console 420 coupled to physical hosts 410 a-410 c by IP network 402. VMM 412 a on physical host 410 a supports the execution of VMs 414 a-414 b, VMM 412 b on physical host 410 b supports the execution of VMs 414 c-414 d, and VMM 412 c on physical host 410 c supports the execution of VMs 414 e-414 f. It should be appreciated the while two VMs are illustrated as being deployed on each of physical hosts 410 a-410 c, more or less than two VMs may be deployed on a physical host. In various embodiments, VMs 414 a-414 f can include VMs of one or more cloud consumers and/or a cloud provider. In the depicted embodiment, each of VMs 414 has one (and may include multiple) virtual network interface controller VNIC1-VNIC6, which provides network connectivity at least at Layers 2 and 3 of the OSI model.
  • VM 414 a utilizes VNIC1 to facilitate communication via a first port of virtual switch 432 a and VM 414 b utilizes VNIC2 to facilitate communication via a second port of virtual switch 432 a. For example, when the first and second ports of virtual switch 432 a are configured as virtual Ethernet bridge (VEB) ports, communications between VM 414 a and VM 414 b may be completely routed via software (e.g., using memory copy operations). As another example, when the first and second ports of virtual switch 432 a are configured as virtual Ethernet port aggregator (VEPA) ports, communications between VM 414 a and VM 414 b are routed through physical NIC 420 a and on network segment 404 a to physical switch 406 a, which routes the communications back to virtual switch 432 a via network segment 404 a and physical NIC 420 a. Similarly, VM 414 c and VM 414 d utilize VNIC3 and VNIC4, respectively, to facilitate communication via different ports of virtual switch 432 b. Likewise, VM 414 e and VM 414 f utilize VNIC5 and VNIC6, respectively, to communicate via different ports of virtual switch 432 c.
  • Referring now to FIG. 5, a relevant portion of physical network switch 406 in data processing environment 400 of FIG. 4 is depicted in accordance with one embodiment of the present disclosure. As is illustrated, physical network switch 406 includes four ports (labeled P1-P4), a crossbar switch 520, a processor 502, and a data storage (e.g., a memory subsystem) 504. While physical network switch 406 is shown with four ports, it should be appreciated that a physical network switch configured according to the present disclosure may include more or less than four ports. Processor 502, which is coupled to crossbar switch 510, controls crossbar switch 520 to switch traffic between ports P1-P4.
  • Data storage 504 includes a legacy OS 508 that runs on top of a Unix-like OS (hereafter assumed to be Linux OS 506, which implements a scheduler 512 that employs a global mutex (GM) 517 that functions as a global lock) and an implementation appropriate number of applications 518. Processor 502 executes a process 519, which is illustrated as including five threads T1-T5. Thread T1 is shown in communication with threads T1 and T3. For example, thread T1 may communicate a wake-up signal to thread T2 (see FIG. 8), when thread T2 has a message whose associated entry is next in run queue 516. As another example, thread T1 may communicate with thread T3 (by storing a message for thread T3 in a message queue 510 associated with thread T3) according to the process of FIG. 7. As is illustrated, two message queues 510 a, 510 b and run queue 516 are allocated (by Linux OS 506) within data storage 504. While only two message queues 510 a, 510 b are illustrated in FIG. 5, it should be appreciated that more or less than two message queues may be implemented in a physical network switch configured according to the present disclosure. In a typical case, each scheduled thread has at least one allocated message queue. Message queues 510 are used to store messages for stem pthreads (and may be used to store messages for Linux pthreads that have been serialized) according to the present disclosure.
  • In one or more embodiments, scheduler 512 implements a routine that allocates GM 517 to a single thread at any given point in time. The GM 517 functions as a global lock to cause stem pthreads (which are normally interruptible threads) and Linux pthreads that have been serialized (e.g., for accessing a common data structure with one or more stem pthreads) to run like stem threads (i.e., as uninterruptible, serialized threads). As is illustrated (in the exploded view) of run queue 516, run queue 516 includes associated entries for five messages for four threads (i.e., threads T1-T4) that are included in process 519. In the illustrated example, thread T5 represents a regular Linux thread that is included in process 519 that remains interruptible. As depicted, an entry associated with a first message for thread T1 is allocated (e.g., by scheduler 512) at a head (indicated with an arrow) of run queue 516 and an entry associated with a second message for thread T1 is allocated at a tail of run queue 516. Associated entries for threads T2, T3, and T4, respectively, are allocated entries (by scheduler 512) in run queue 516 between the head and the tail of run queue 516. As is discussed in further detail in FIG. 8, messages for the threads T1-T4 are serially processed in the order of the associated entries in run queue 516.
  • As noted above, to ensure compatibility with applications 518, restrictions are enforced on stem pthreads that differentiate stem pthreads from Linux pthreads. To ensure that stem pthreads get scheduled in the same order as the messages are posted (to emulate the legacy software), an associated entry in run queue 516 is maintained for each stem pthread message that requires processing. In one or more embodiments, a stem pthread (or serialized Linux pthread) may have more than one associated message queue 510, each of which has a different priority. In this case, messages with a higher priority may be routed (by, for example, a sending thread) to a higher priority message queue and messages with a lower priority may be routed to a lower priority message queue. In this case, messages in a higher priority message queue, if any, are processed before messages in a lower priority message queue.
  • Scheduler 512, implemented within Linux OS 506, maintains various background information on scheduled threads and an API layer (that executes on top of the scheduler 512) maintains housekeeping information (e.g., whether a scheduled thread is a stem pthread or a Linux pthread). As noted above, according to one or more aspects of the present disclosure, when a thread is a stem pthread, the thread always requires serialization. According to the present disclosure, each thread (i.e., stem pthreads and Linux pthreads) includes code that is configured to process messages within message queues 510. As mentioned above, new software modules that are added to physical network switch 406 may employ Linux pthreads. As noted above, when a Linux pthread needs to access any data structure that is shared with a stem pthread, the Linux pthread can be temporarily serialized by creating an entry for the Linux pthread in run queue 516. For example, threads T1 and T4 may be stem pthreads and threads T2 and T3 may be serialized Linux pthreads.
  • With reference now to FIG. 6, there is illustrated a high level logical flowchart of an exemplary method of determining whether threads in a computing environment require serialization in accordance with one embodiment of the present disclosure. As previously mentioned, threads that require serialization my be stem pthreads or Linux pthreads that require access to a data structure that is shared with a stem pthread. The flowchart of FIG. 6 depicts steps in logical rather than strictly chronological order. Thus, in at least some embodiments, at least some steps of a logical flowchart can be performed in a different order than illustrated or concurrently. The process illustrated in FIG. 6 can be performed by Linux OS 506 of each physical network switch 406 in data processing environment 400 of FIG. 4.
  • The process begins at block 600 and then proceeds to decision block 602, where Linux OS 506 determines whether a thread that is to be scheduled requires serialization. In response to thread not requiring serialization in block 602, control transfers to block 608. In response to the thread requiring serialization in block 602, control transfers to block 604. In block 604, Linux OS 506 allocates an entry for the thread in run queue 516. Then, in block 606, Linux OS 506 allocates one or more message queues 510 for the thread. For example, a single message queue may be allocated when a thread does not receive messages with different priorities. As another example, a high priority message queue and a low priority message queue may be allocated when a thread receives messages with two different priorities. Following block 606, control passes to block 608 where the process depicted in FIG. 6 ends.
  • With reference now to FIG. 7, there is illustrated a high level logical flowchart of an exemplary method of performing inter-thread communication in a computing environment in accordance with one embodiment of the present disclosure. In this case, the serialized threads may be stem pthreads or Linux pthreads that require access to a data structure that is shared with a stem pthread. The flowchart of FIG. 7 depicts steps in logical rather than strictly chronological order. Thus, in at least some embodiments, at least some steps of a logical flowchart can be performed in a different order than illustrated or concurrently. The process illustrated in FIG. 7 can be performed by, for example, each physical network switch 406 in data processing environment 400 of FIG. 4.
  • The process begins at block 700 and then proceeds to decision block 702, where a sending thread (e.g., thread T1) determines whether an inter-thread communication (e.g., to share data) is indicated. In response to an inter-thread communication not being indicated in block 702, control transfers to block 710, where the process depicted in FIG. 7 ends. In response to an inter-thread communication being indicated in block 702, control transfers to block 704 where the sending thread retrieves (e.g., from scheduler 512) a global ID (which indicates a particular message queue 510) for a receiving thread (e.g., thread T3). Next, in block 706, the sending thread determines if a priority for the communication is indicated (i.e., whether the thread has multiple associated message queues 510). Then, in block 708, the sending thread stores a message for the receiving thread in a message queue 510 of the receiving thread. For example, if a low priority message is indicated (e.g., based on a traffic type), the message for the receiving thread is stored (by the sending thread) in a low priority message queue. Similarly, if a high priority message is indicated, the message for the receiving thread is stored (by the sending thread) in a high priority message queue. Following block 708, control passes to block 710 where the process depicted in FIG. 7 ends.
  • With reference now to FIG. 8, there is illustrated a high level logical flowchart of an exemplary method of executing a serialized thread in a computing environment in accordance with one embodiment of the present disclosure. The serialized thread may be a stem pthread or a Linux pthread that requires serialization to, for example, access a data structure that is shared with a stem pthread. The flowchart of FIG. 8 depicts steps in logical rather than strictly chronological order. Thus, in at least some embodiments, at least some steps of a logical flowchart can be performed in a different order than illustrated or concurrently. The process illustrated in FIG. 8 can be performed by, for example, each physical network switch 406 in data processing environment 400 of FIG. 4.
  • The process begins at block 800 and then proceeds to decision block 802, where a sleeping thread (e.g., thread T1 of process 519, which may be a stem pthread or a Linux pthread that has been serialized) determines whether a wake-up signal has been received (e.g., from another thread). As noted above, a sleeping thread receives a wake-up signal to process a message in response to an associated entry for the message reaching a head of run queue 516. In various embodiments, the wake-up signal for a sleeping thread is triggered following an event (e.g., receipt of a message for the first thread from another thread, arrival of a packet for the first thread, a timer expiration associated with the first thread, or establishment of a link for the first thread) and is generated subsequent to the associated entry for the message for the sleeping thread reaching the head of run queue 516. Next, in block 804, the sleeping thread wakes up in response to receiving the wake-up signal, thus becoming an active thread. Then, in block 806, the active thread waits to receive the global lock (GM 517) from scheduler 512. Upon receiving GM 517 from scheduler 512, the active thread retrieves the message from an associated message queue 510 in block 810 and processes the retrieved message in block 810.
  • Next, in block 812, the active thread checks run queue 516 for additional entries. Then, in block 814, the active thread determines whether run queue 516 is empty. In response to run queue 516 being empty in block 814, control transfers to decision block 818. In response to run queue 516 not being empty in block 814, control transfers to block 816 where the active thread wakes up another thread (e.g., thread T2) having a message associated with a next entry in run queue 516. Following block 816, control transfers to block 818. In block 818, the active thread determines whether it has another message in an associated message queue 510 to process. In response to the active thread not having another message to process in block 818, control transfers to block 826 where the active thread releases the global lock. In response to the active thread having another message to process in block 818, control transfers to block 820 where the active thread queues an associated entry for the message to an end of run queue 516.
  • Next, in decision block 822 the active thread determines whether it is the only thread with an entry in run queue 516. In response to the active thread determining that it is the only thread with an entry in run queue 516, the active thread continues the process of FIG. 8 at block 808 where a next message in an associated message queue 510 for the active thread is retrieved. In response to the active thread determining that it is not the only thread with an entry in run queue 516, control transfers to block 826 where the active thread releases the global lock. Next, in block 828, the active thread goes to sleep. Following block 828, control passes to block 830 where the process depicted in FIG. 8 ends.
  • In the event that it is desirable for an active thread to release the global lock even when no other thread currently has a message to be processed and the active thread currently has another message to be processed, blocks 822 and 824 may be omitted. In this case, the output of block 820 is routed directly to block 826.
  • Accordingly, techniques have been disclosed herein that facilitate seamless communication between multiple heterogeneous execution threads within a single process. The disclosed techniques also facilitate operating Linux pthreads as freely schedulable threads or as stem threads (i.e., Linux pthreads may serialized to be uninterruptible).
  • While the present invention has been particularly shown as described with reference to one or more preferred embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention. For example, it should be understood that although the detailed description provided herein provides multiple embodiments of cloud computing environments, the teachings disclosed herein are not limited to cloud computing environments. Rather, embodiments can be implemented in any other type of computing environment now known or later developed, including client-server and peer-to-peer computing environments. The disclosed techniques are broadly applicable to virtualized and non-virtualized computing environments and may be implemented in devices (e.g., host platforms) other than physical network switches.
  • Further, although aspects have been described with respect to computer systems executing program code that direct the functions described herein, it should be understood that embodiments may alternatively be implemented as a program product including a storage medium (e.g., data storage 310) storing program code that can be processed by a data processing system to cause the data processing system to perform one or more of the described functions.

Claims (14)

1-7. (canceled)
8. A data processing system configured to execute normally interruptible threads of a process in a non-preemptive manner, the data processing system comprising:
a data storage including program code; and
a processor coupled to the data storage, wherein the program code, when executed by the processor, configures the processor for:
in response to a first entry associated with a first message for a first thread reaching a head of a run queue, receiving, by the first thread, a first wake-up signal;
in response to receiving the wake-up signal, waiting, by the first thread, for a global lock;
in response to the first thread receiving the global lock, retrieving, by the first thread, the first message from an associated message queue;
processing, by the first thread, the retrieved first message;
in response to completing the processing of the first message, transmitting, by the first thread, a second wake-up signal to a second thread whose associated entry is next in the run queue; and
releasing, by the first thread, the global lock following the transmitting of the second wake-up signal.
9. The data processing system of claim 8, wherein the program code, when executed by the processor, further configures the processor for:
checking, by the first thread, the associated message queue for a second message for the first thread; and
in response to the associated message queue including the second message, queueing a second entry associated with the second message to an end of the run queue.
10. The data processing system of claim 8, wherein the second thread is a Linux pthread that requires access to a data structure that is shared with the first thread.
11. The data processing system of claim 8, wherein the first wake-up signal is triggered following an event.
12. The data processing system of claim 11, wherein the event corresponds to one of: receipt of a message for the first thread from another thread, arrival of a packet for the first thread, a timer expiration associated with the first thread, and establishment of a link for the first thread.
13. The data processing system of claim 8, wherein one of the first and second threads is a stem pthread and a remaining one of the first and second threads is a Linux pthread that has been serialized.
14. The data processing system of claim 8, wherein the first and second threads are stem pthreads.
15. A program product including program code, embodied in a data storage, for executing normally interruptible threads of a process in a non-preemptive manner, the program code, when executed by a data processing system, configuring the data processing system for:
in response to a first entry associated with a first message for a first thread reaching a head of a run queue, receiving, by the first thread, a first wake-up signal;
in response to receiving the wake-up signal, waiting, by the first thread, for a global lock;
in response to the first thread receiving the global lock, retrieving, by the first thread, the first message from an associated message queue;
processing, by the first thread, the retrieved first message;
in response to completing the processing of the first message, transmitting, by the first thread, a second wake-up signal to a second thread whose associated entry is next in the run queue; and
releasing, by the first thread, the global lock following the transmitting of the second wake-up signal.
16. The program product of claim 15, wherein the program code, when executed by the data processing system, further configures the data processing system for:
checking, by the first thread, the associated message queue for a second message for the first thread; and
in response to the associated message queue including the second message, queueing a second entry associated with the second message to an end of the run queue.
17. The program product of claim 15, wherein the second thread is a Linux pthread that requires access to a data structure that is shared with the first thread.
18. The program product of claim 15, wherein the first wake-up signal is triggered following an event, and wherein the event corresponds to one of: receipt of a message for the first thread from another thread, arrival of a packet for the first thread, a timer expiration associated with the first thread, and establishment of a link for the first thread.
19. The program product of claim 15, wherein one of the first and second threads is a stem pthread and a remaining one of the first and second threads is a Linux pthread that has been serialized.
20. The program product of claim 15, wherein the first and second threads are stem pthreads.
US13/107,896 2011-05-14 2011-05-14 Techniques for executing threads in a computing environment Abandoned US20120291034A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/107,896 US20120291034A1 (en) 2011-05-14 2011-05-14 Techniques for executing threads in a computing environment

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/107,896 US20120291034A1 (en) 2011-05-14 2011-05-14 Techniques for executing threads in a computing environment
CN201210147169.0A CN102841810B (en) 2011-05-14 2012-05-11 Method and system for executing threads in a computing environment
US13/602,365 US8856801B2 (en) 2011-05-14 2012-09-04 Techniques for executing normally interruptible threads in a non-preemptive manner

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/602,365 Continuation US8856801B2 (en) 2011-05-14 2012-09-04 Techniques for executing normally interruptible threads in a non-preemptive manner

Publications (1)

Publication Number Publication Date
US20120291034A1 true US20120291034A1 (en) 2012-11-15

Family

ID=47142774

Family Applications (2)

Application Number Title Priority Date Filing Date
US13/107,896 Abandoned US20120291034A1 (en) 2011-05-14 2011-05-14 Techniques for executing threads in a computing environment
US13/602,365 Active 2031-12-05 US8856801B2 (en) 2011-05-14 2012-09-04 Techniques for executing normally interruptible threads in a non-preemptive manner

Family Applications After (1)

Application Number Title Priority Date Filing Date
US13/602,365 Active 2031-12-05 US8856801B2 (en) 2011-05-14 2012-09-04 Techniques for executing normally interruptible threads in a non-preemptive manner

Country Status (2)

Country Link
US (2) US20120291034A1 (en)
CN (1) CN102841810B (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130047151A1 (en) * 2011-08-16 2013-02-21 Microsoft Corporation Virtualization gateway between virtualized and non-virtualized networks
US8769550B1 (en) * 2012-10-24 2014-07-01 Sprint Communications Company L.P. Reply queue management
CN104572881A (en) * 2014-12-23 2015-04-29 国家电网公司 Method for importing distribution network graph model based on multi-task concurrency
US9092282B1 (en) 2012-08-14 2015-07-28 Sprint Communications Company L.P. Channel optimization in a messaging-middleware environment
US9264338B1 (en) 2013-04-08 2016-02-16 Sprint Communications Company L.P. Detecting upset conditions in application instances
US20160179518A1 (en) * 2014-12-23 2016-06-23 International Business Machines Corporation Non-serialized push instruction for pushing a message payload from a sending thread to a receiving thread
US20160204999A1 (en) * 2015-01-13 2016-07-14 Fujitsu Limited Monitoring apparatus and information processing system
US9678812B2 (en) 2014-12-22 2017-06-13 International Business Machines Corporation Addressing for inter-thread push communication

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9294347B2 (en) * 2014-03-20 2016-03-22 Dell Products Lp Systems and methods for automatic access layer configuration
CN104834566B (en) * 2015-03-31 2018-09-07 华为技术有限公司 Forwarding processing method for adjusting the thread switch port and associated apparatus
CN106250214A (en) * 2015-06-05 2016-12-21 苹果公司 Media analysis and processing framework on resource restricted device
CN106201705A (en) * 2016-07-25 2016-12-07 东软集团股份有限公司 Method and device for processing messages
CN106933681A (en) * 2017-02-05 2017-07-07 深圳怡化电脑股份有限公司 Multi-object blocking method and system thereof
CN107102582A (en) * 2017-04-07 2017-08-29 深圳怡化电脑股份有限公司 Subsystem command synchronization method and device

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040103110A1 (en) * 2002-11-25 2004-05-27 International Business Machines Corporation Systems, methods, and computer program products to optimize serialization when porting code to IBM S/390 UNIX system services from a UNIX system
US20050080963A1 (en) * 2003-09-25 2005-04-14 International Business Machines Corporation Method and system for autonomically adaptive mutexes
US20070088792A1 (en) * 2005-10-15 2007-04-19 Piper Scott A Hardware processing of commands within virtual client computing environment
US20090037927A1 (en) * 2007-07-30 2009-02-05 Vasudevan Sangili Apparatus and method for direct switching of software threads
US7802257B1 (en) * 2005-06-20 2010-09-21 Oracle America, Inc. Mechanism for bridging a thread-oriented computing paradigm and a job-oriented computing paradigm
US20100242043A1 (en) * 2009-03-18 2010-09-23 Charles Scott Shorb Computer-Implemented Systems For Resource Level Locking Without Resource Level Locks
US20110246970A1 (en) * 2010-03-30 2011-10-06 Nec Laboratories America, Inc. Interval analysis of concurrent trace programs using transaction sequence graphs

Family Cites Families (110)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5394402A (en) 1993-06-17 1995-02-28 Ascom Timeplex Trading Ag Hub for segmented virtual local area network with shared media access
US5617421A (en) 1994-06-17 1997-04-01 Cisco Systems, Inc. Extended domain computer network using standard links
US5515359A (en) 1994-08-26 1996-05-07 Mitsubishi Electric Research Laboratories, Inc. Credit enhanced proportional rate control system
US5633859A (en) 1994-09-16 1997-05-27 The Ohio State University Method and apparatus for congestion management in computer networks using explicit rate indication
ZA9509722B (en) 1994-12-19 1996-05-31 Alcatel Nv Traffic management and congestion control for packet-based networks
US6035105A (en) 1996-01-02 2000-03-07 Cisco Technology, Inc. Multiple VLAN architecture system
US5742604A (en) 1996-03-28 1998-04-21 Cisco Systems, Inc. Interswitch link mechanism for connecting high-performance network switches
US5832484A (en) * 1996-07-02 1998-11-03 Sybase, Inc. Database system with methods for parallel lock management
EP0853405A3 (en) 1997-01-06 1998-09-16 Digital Equipment Corporation Ethernet network with credit based flow control
US5893320A (en) 1997-05-20 1999-04-13 Demaree; Michael S. Device for cooking fowl
US6192406B1 (en) 1997-06-13 2001-02-20 At&T Corp. Startup management system and method for networks
US6147970A (en) 1997-09-30 2000-11-14 Gte Internetworking Incorporated Quality of service management for aggregated flows in a network system
US6567403B1 (en) 1998-04-30 2003-05-20 Hewlett-Packard Development Company, L.P. Virtual-chassis switch network topology
US6609153B1 (en) 1998-12-24 2003-08-19 Redback Networks Inc. Domain isolation through virtual network machines
US6347337B1 (en) 1999-01-08 2002-02-12 Intel Corporation Credit based flow control scheme over virtual interface architecture for system area networks
US6646985B1 (en) 1999-06-03 2003-11-11 Fujitsu Network Communications, Inc. Congestion control mechanism in a network access device
US6901452B1 (en) 2000-03-02 2005-05-31 Alcatel Selectable prioritization for data communication switch
US6880086B2 (en) 2000-05-20 2005-04-12 Ciena Corporation Signatures for facilitating hot upgrades of modular software components
US6947419B2 (en) 2001-06-12 2005-09-20 Acute Technology Corp. Apparatus for multicast forwarding in a virtual local area network environment
US7042842B2 (en) 2001-06-13 2006-05-09 Computer Network Technology Corporation Fiber channel switch
US7263060B1 (en) 2001-06-28 2007-08-28 Network Appliance, Inc. Multiple switch protected architecture
US7173934B2 (en) 2001-09-10 2007-02-06 Nortel Networks Limited System, device, and method for improving communication network reliability using trunk splitting
US7035220B1 (en) 2001-10-22 2006-04-25 Intel Corporation Technique for providing end-to-end congestion control with no feedback from a lossless network
US7561517B2 (en) 2001-11-02 2009-07-14 Internap Network Services Corporation Passive route control of data networks
US7668966B2 (en) 2001-11-02 2010-02-23 Internap Network Services Corporation Data network controller
US20030185206A1 (en) 2002-03-29 2003-10-02 Bhaskar Jayakrishnan Destination device bit map for delivering an information packet through a switch fabric
KR100472416B1 (en) 2002-11-01 2005-03-11 삼성전자주식회사 Device and Method for Controlling Packet Flow
US7702729B2 (en) 2003-04-08 2010-04-20 Johanson Bradley E Event heap: a coordination infrastructure for dynamic heterogeneous application interactions in ubiquitous computing environments
JP2004355125A (en) 2003-05-27 2004-12-16 Pioneer Electronic Corp Software update processing device, system, its method and program, and recording medium with the program recorded thereon
US7508763B2 (en) 2003-09-04 2009-03-24 Hewlett-Packard Development Company, L.P. Method to regulate traffic congestion in a network
US7386848B2 (en) * 2003-10-02 2008-06-10 International Business Machines Corporation Method and system to alleviate denial-of-service conditions on a server
JP2007507990A (en) 2003-10-14 2007-03-29 ラプター・ネツトワークス・テクノロジー・インコーポレイテツド Switching system comprising a distributed switching structure
CN101087238B (en) 2003-10-21 2010-08-04 华为技术有限公司 Dynamic bandwidth allocation device and method of passive optical network
US7483370B1 (en) 2003-12-22 2009-01-27 Extreme Networks, Inc. Methods and systems for hitless switch management module failover and upgrade
US7593320B1 (en) 2004-04-30 2009-09-22 Marvell International, Ltd. Failover scheme for stackable network switches
US7475397B1 (en) * 2004-07-28 2009-01-06 Sun Microsystems, Inc. Methods and apparatus for providing a remote serialization guarantee
GB2418326B (en) 2004-09-17 2007-04-11 Hewlett Packard Development Co Network vitrualization
US7564869B2 (en) 2004-10-22 2009-07-21 Cisco Technology, Inc. Fibre channel over ethernet
US7830793B2 (en) 2004-10-22 2010-11-09 Cisco Technology, Inc. Network device architecture for consolidating input/output and reducing latency
US8238347B2 (en) 2004-10-22 2012-08-07 Cisco Technology, Inc. Fibre channel over ethernet
US7974223B2 (en) 2004-11-19 2011-07-05 Corrigent Systems Ltd. Virtual private LAN service over ring networks
US20070036178A1 (en) 2005-02-02 2007-02-15 Susan Hares Layer 2 virtual switching environment
US8194534B2 (en) 2005-02-28 2012-06-05 International Business Machines Corporation Blade server system with at least one rack-switch having multiple switches interconnected and configured for management and operation as a single virtual switch
US8085657B2 (en) 2005-04-01 2011-12-27 Sony Corporation Flow control in a cellular communication system
CN100486216C (en) 2005-07-15 2009-05-06 华为技术有限公司 Method for improving transmission reliability in virtual exchange system
US7962923B2 (en) * 2005-12-30 2011-06-14 Level 3 Communications, Llc System and method for generating a lock-free dual queue
CN100571249C (en) 2006-02-27 2009-12-16 中兴通讯股份有限公司 Ethernet coomunication method for determining realtime transmission
US7515535B2 (en) 2006-05-10 2009-04-07 Cisco Technology, Inc. Technique for efficiently managing bandwidth for multipoint-to-multipoint services in a provider network
US8498284B2 (en) 2007-02-02 2013-07-30 Interdigital Technology Corporation Method and apparatus for enhancing RLC for flexible RLC PDU size
US9661112B2 (en) 2007-02-22 2017-05-23 International Business Machines Corporation System and methods for providing server virtualization assistance
US8140696B2 (en) 2007-03-12 2012-03-20 International Business Machines Corporation Layering serial attached small computer system interface (SAS) over ethernet
US8320245B2 (en) 2007-03-13 2012-11-27 Alcatel Lucent Policy enforcement points
JP4888186B2 (en) 2007-03-28 2012-02-29 富士通株式会社 Communication system, relay, relay method
US8559429B2 (en) 2007-06-11 2013-10-15 International Business Machines Corporation Sequential frame forwarding
US9667442B2 (en) 2007-06-11 2017-05-30 International Business Machines Corporation Tag-based interface between a switching device and servers for use in frame processing and forwarding
US7912003B2 (en) 2007-06-27 2011-03-22 Microsoft Corporation Multipath forwarding algorithms using network coding
WO2009042735A1 (en) 2007-09-25 2009-04-02 Blade Network Technologies, Inc. Apparatus for externally changing the direction of air flowing through electronic equipment
US7839777B2 (en) 2007-09-27 2010-11-23 International Business Machines Corporation Method, system, and apparatus for accelerating resolution of network congestion
US20090125882A1 (en) * 2007-10-08 2009-05-14 Matteo Frigo Method of implementing hyperobjects in a parallel processing software programming environment
US8867341B2 (en) 2007-11-09 2014-10-21 International Business Machines Corporation Traffic management of client traffic at ingress location of a data center
US8553537B2 (en) 2007-11-09 2013-10-08 International Business Machines Corporation Session-less load balancing of client traffic across servers in a server group
US7835306B2 (en) 2008-01-23 2010-11-16 Cisco Technology, Inc. Translating MST instances between ports of a bridge in a computer network
US8625592B2 (en) 2008-02-26 2014-01-07 Cisco Technology, Inc. Blade switch with scalable interfaces
US20110035494A1 (en) 2008-04-15 2011-02-10 Blade Network Technologies Network virtualization for a virtualized server data center environment
US8131983B2 (en) * 2008-04-28 2012-03-06 International Business Machines Corporation Method, apparatus and article of manufacture for timeout waits on locks
US8385202B2 (en) 2008-08-27 2013-02-26 Cisco Technology, Inc. Virtual switch quality of service for virtual machines
US9426095B2 (en) 2008-08-28 2016-08-23 International Business Machines Corporation Apparatus and method of switching packets between virtual ports
US9237034B2 (en) 2008-10-21 2016-01-12 Iii Holdings 1, Llc Methods and systems for providing network access redundancy
US7929554B2 (en) 2008-12-23 2011-04-19 Cisco Technology, Inc. Optimized forwarding for provider backbone bridges with both I and B components (IB-PBB)
CN102334112B (en) 2009-02-27 2014-06-11 美国博通公司 Method and system for virtual machine networking
US9031081B2 (en) 2009-08-06 2015-05-12 Broadcom Corporation Method and system for switching in a virtualized platform
US8238340B2 (en) 2009-03-06 2012-08-07 Futurewei Technologies, Inc. Transport multiplexer—mechanisms to force ethernet traffic from one domain to be switched in a different (external) domain
US8265075B2 (en) 2009-03-16 2012-09-11 International Business Machines Corporation Method and apparatus for managing, configuring, and controlling an I/O virtualization device through a network switch
US8665886B2 (en) 2009-03-26 2014-03-04 Brocade Communications Systems, Inc. Redundant host connection in a routed network
EP2804350A1 (en) 2009-04-01 2014-11-19 Nicira, Inc. Method and apparatus for implementing and managing virtual switches
US8325598B2 (en) 2009-05-20 2012-12-04 Verizon Patent And Licensing Inc. Automatic protection switching of virtual connections
US8174984B2 (en) 2009-05-29 2012-05-08 Oracle America, Inc. Managing traffic on virtualized lanes between a network switch and a virtual machine
US8638799B2 (en) 2009-07-10 2014-01-28 Hewlett-Packard Development Company, L.P. Establishing network quality of service for a virtual machine
US8204061B1 (en) 2009-07-23 2012-06-19 Cisco Technology, Inc. Virtual port channel switches with distributed control planes
US8125928B2 (en) 2009-07-24 2012-02-28 Juniper Networks, Inc. Routing frames in a shortest path computer network for a multi-homed legacy bridge node
US8625427B1 (en) 2009-09-03 2014-01-07 Brocade Communications Systems, Inc. Multi-path switching with edge-to-edge flow control
US8537860B2 (en) 2009-11-03 2013-09-17 International Business Machines Corporation Apparatus for switching traffic between virtual machines
US8665747B2 (en) 2009-12-03 2014-03-04 Cisco Technology, Inc. Preventing loops on network topologies built with virtual switches and VMS
US8369335B2 (en) 2010-03-24 2013-02-05 Brocade Communications Systems, Inc. Method and system for extending routing domain to non-routing end stations
US8625616B2 (en) 2010-05-11 2014-01-07 Brocade Communications Systems, Inc. Converged network extension
WO2011150396A1 (en) 2010-05-28 2011-12-01 Huawei Technologies Co., Ltd. Virtual layer 2 and mechanism to make it scalable
US8885488B2 (en) 2010-06-02 2014-11-11 Brocade Communication Systems, Inc. Reachability detection in trill networks
US8634308B2 (en) 2010-06-02 2014-01-21 Brocade Communications Systems, Inc. Path detection in trill networks
US8446914B2 (en) 2010-06-08 2013-05-21 Brocade Communications Systems, Inc. Method and system for link aggregation across multiple switches
US9246703B2 (en) 2010-06-08 2016-01-26 Brocade Communications Systems, Inc. Remote port mirroring
US20110299533A1 (en) 2010-06-08 2011-12-08 Brocade Communications Systems, Inc. Internal virtual network identifier and internal policy identifier
US8406128B1 (en) 2010-06-29 2013-03-26 Amazon Technologies, Inc. Efficient highly connected data centers
US8588081B2 (en) 2010-07-14 2013-11-19 Cisco Technology, Inc. Monitoring a flow set to detect faults
US8873551B2 (en) 2010-07-30 2014-10-28 Cisco Technology, Inc. Multi-destination forwarding in network clouds which include emulated switches
US8488608B2 (en) 2010-08-04 2013-07-16 Alcatel Lucent System and method for traffic distribution in a multi-chassis link aggregation
US8345697B2 (en) 2010-08-17 2013-01-01 Dell Products, Lp System and method for carrying path information
US8498299B2 (en) 2010-08-19 2013-07-30 Juniper Networks, Inc. Flooding-based routing protocol having average-rate and burst-rate control
US9749241B2 (en) 2010-11-09 2017-08-29 International Business Machines Corporation Dynamic traffic management in a data center
US20120131662A1 (en) 2010-11-23 2012-05-24 Cisco Technology, Inc. Virtual local area networks in a virtual machine environment
US20120163164A1 (en) 2010-12-27 2012-06-28 Brocade Communications Systems, Inc. Method and system for remote load balancing in high-availability networks
US9071630B2 (en) 2011-01-07 2015-06-30 Jeda Networks, Inc. Methods for the interconnection of fibre channel over ethernet devices using a trill network
US8478961B2 (en) 2011-03-02 2013-07-02 International Business Machines Corporation Dynamic migration of virtual machines based on workload cache demand profiling
KR101780423B1 (en) 2011-03-18 2017-09-22 삼성전자주식회사 Semiconductor device and method of forming the same
US8755383B2 (en) 2011-03-21 2014-06-17 Avaya, Inc. Usage of masked ethernet addresses between transparent interconnect of lots of links (TRILL) routing bridges
US8787377B2 (en) 2011-03-21 2014-07-22 Avaya, Inc. Usage of masked BMAC addresses in a provider backbone bridged (PBB) network
US8837499B2 (en) 2011-05-14 2014-09-16 International Business Machines Corporation Distributed fabric protocol (DFP) switching network architecture
US8588224B2 (en) 2011-05-14 2013-11-19 International Business Machines Corporation Priority based flow control in a distributed fabric protocol (DFP) switching network architecture
US20120287785A1 (en) 2011-05-14 2012-11-15 International Business Machines Corporation Data traffic handling in a distributed fabric protocol (dfp) switching network architecture
US9736085B2 (en) 2011-08-29 2017-08-15 Brocade Communications Systems, Inc. End-to end lossless Ethernet in Ethernet fabric
US8767529B2 (en) 2011-09-12 2014-07-01 International Business Machines Corporation High availability distributed fabric protocol (DFP) switching network architecture

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040103110A1 (en) * 2002-11-25 2004-05-27 International Business Machines Corporation Systems, methods, and computer program products to optimize serialization when porting code to IBM S/390 UNIX system services from a UNIX system
US20050080963A1 (en) * 2003-09-25 2005-04-14 International Business Machines Corporation Method and system for autonomically adaptive mutexes
US7802257B1 (en) * 2005-06-20 2010-09-21 Oracle America, Inc. Mechanism for bridging a thread-oriented computing paradigm and a job-oriented computing paradigm
US20070088792A1 (en) * 2005-10-15 2007-04-19 Piper Scott A Hardware processing of commands within virtual client computing environment
US20090037927A1 (en) * 2007-07-30 2009-02-05 Vasudevan Sangili Apparatus and method for direct switching of software threads
US20100242043A1 (en) * 2009-03-18 2010-09-23 Charles Scott Shorb Computer-Implemented Systems For Resource Level Locking Without Resource Level Locks
US20110246970A1 (en) * 2010-03-30 2011-10-06 Nec Laboratories America, Inc. Interval analysis of concurrent trace programs using transaction sequence graphs

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9274825B2 (en) * 2011-08-16 2016-03-01 Microsoft Technology Licensing, Llc Virtualization gateway between virtualized and non-virtualized networks
US20130047151A1 (en) * 2011-08-16 2013-02-21 Microsoft Corporation Virtualization gateway between virtualized and non-virtualized networks
US9935920B2 (en) 2011-08-16 2018-04-03 Microsoft Technology Licensing, Llc Virtualization gateway between virtualized and non-virtualized networks
US9092282B1 (en) 2012-08-14 2015-07-28 Sprint Communications Company L.P. Channel optimization in a messaging-middleware environment
US8769550B1 (en) * 2012-10-24 2014-07-01 Sprint Communications Company L.P. Reply queue management
US9264338B1 (en) 2013-04-08 2016-02-16 Sprint Communications Company L.P. Detecting upset conditions in application instances
US9678812B2 (en) 2014-12-22 2017-06-13 International Business Machines Corporation Addressing for inter-thread push communication
US9684551B2 (en) 2014-12-22 2017-06-20 International Business Machines Corporation Addressing for inter-thread push communication
CN104572881A (en) * 2014-12-23 2015-04-29 国家电网公司 Method for importing distribution network graph model based on multi-task concurrency
US20160179518A1 (en) * 2014-12-23 2016-06-23 International Business Machines Corporation Non-serialized push instruction for pushing a message payload from a sending thread to a receiving thread
US9766890B2 (en) * 2014-12-23 2017-09-19 International Business Machines Corporation Non-serialized push instruction for pushing a message payload from a sending thread to a receiving thread
US9778933B2 (en) * 2014-12-23 2017-10-03 International Business Machines Corporation Non-serialized push instruction for pushing a message payload from a sending thread to a receiving thread
US20160179517A1 (en) * 2014-12-23 2016-06-23 International Business Machines Corporation Non-serialized push instruction for pushing a message payload from a sending thread to a receiving thread
US20160204999A1 (en) * 2015-01-13 2016-07-14 Fujitsu Limited Monitoring apparatus and information processing system

Also Published As

Publication number Publication date
CN102841810B (en) 2015-07-22
CN102841810A (en) 2012-12-26
US20120324460A1 (en) 2012-12-20
US8856801B2 (en) 2014-10-07

Similar Documents

Publication Publication Date Title
Pahl Containerization and the paas cloud
Peter et al. Arrakis: The operating system is the control plane
US9253211B2 (en) Managing communications between computing nodes
Figueiredo et al. A case for grid computing on virtual machines
CA2697540C (en) Executing programs based on user-specified constraints
Di Costanzo et al. Harnessing cloud technologies for a virtualized distributed computing infrastructure
Wang et al. Scientific cloud computing: Early definition and experience
US9450783B2 (en) Abstracting cloud management
US8271653B2 (en) Methods and systems for cloud management using multiple cloud management schemes to allow communication between independently controlled clouds
US20120203823A1 (en) Apparatus, systems and methods for deployment and management of distributed computing systems and applications
US20160127206A1 (en) Rack awareness data storage in a cluster of host computing devices
US20120204187A1 (en) Hybrid Cloud Workload Management
JP5275407B2 (en) The method for the network interface is shared by multiple virtual machines
US20090271498A1 (en) System and method for layered application server processing
US20120291028A1 (en) Securing a virtualized computing environment using a physical network switch
US8301746B2 (en) Method and system for abstracting non-functional requirements based deployment of virtual machines
García-Valls et al. Challenges in real-time virtualization and predictable cloud computing
US8959523B2 (en) Automated virtual machine placement planning using different placement solutions at different hierarchical tree levels
CN102262557B (en) Method for constructing virtual machine monitor by bus architecture and performance service framework
US8988998B2 (en) Data processing environment integration control
US9571332B2 (en) Methods and apparatuses for remote application provisioning automation over virtualized IT infrastructure
US8462632B1 (en) Network traffic control
US20130238785A1 (en) System and Method for Metadata Discovery and Metadata-Aware Scheduling
AU2013232273B2 (en) Method and system for utilizing spare cloud resources
CN103226489B (en) Means for creating a virtual computing environment in a method and system

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KAMATH, DAYAVANTI G.;GHOSH, NIRAPADA;LEU, DAR-REN;AND OTHERS;REEL/FRAME:026666/0692

Effective date: 20110712

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE