GB2472060A - FIFO queue coupling device for communication between systems using Posix pipe semantics - Google Patents

Abstract

A coupling device for communication between operating systems in a cluster has a number of FIFO queues. The operating systems have an application programming interface which uses Posix pipe semantics to read from and write to the queues. The coupling device maintains the data structures and locks needed to represent Posix pipes. This allows the use of standard mount, open, write, read and close function calls to the operating system kernel to be used to access the FIFO queues on the coupling device. If one of the operating systems connected to the coupling device crashes, the device repairs the data structures associated with the queues. The operating systems may run on a single computer system or may be distributed across several computer systems.

Description

INTELLECTUAL

. .... PROPERTY OFFICE Application No. GB09 12800.0 RTM Date:29 October 2009 The following terms are registered trademarks and should be read as such wherever they occur in this document: Unix Linux Intellectual Property Office is an operating name of the Patent Office www.ipo.gov.uk

SYSTEMS AND METHODS TO IMPLEMENT POSIX COMPLIANT CLUSTER

FIFO WITH COUPLING DEVICE

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention generally relates to systems and methods for implementing a coupling device to connect multiple operating systems running software that uses Portable Standard Operating System (POSIX) compliant Application Programming Interface (API) to efficiently communicate with a FIFO (first-in, first out) semantics via the coupling device.

Description of the Related Art

A coupling device is a cluster communication medium connected to multiple operating systems. The coupling device has one or more queues to which multiple operating systems can write data to and read data from.

Conventionally, a coupling device is a cluster communication medium connected to multiple operating system instances on which one or more queues can be allocated. When communication is performed through a queue on a coupling device, that queue remembers data sent via the channel until the data has been fetched by the receiver. A set of queues can be grouped into a queue area. Each queue in a queue area consists of queue entries that each may hold a maximal amount of data. Each entry comprises standard data parts and adjunct data parts.

In addition to queues, a queue area can also contain lock structures on which atomic lock operations can be performed. Atomic lock operations atomically test the current lock value or modify a lock value only if a caller knows the current lock value.

Coupling devices offer the following synchronous atomic operations on its queues: writing of an entry to the end of a queue, reading an entry from the beginning of a queue, reading and deleting an entry from the beginning of a queue, updating an entry at the beginning of the queue, and deleting an entry from the beginning of a queue. These coupling device operations can be combined with one lock operation into a single atomic operation such that the queue operation only succeeds if the lock operation succeeds.

In addition to queues and locks, a queue area provides some general storage area to store information.

While coupling devices do exist, for example, the system disclosed in U.S. Patent No. 6,999,997 B2 (the entirety of which is incorporated herein by reference), they have limited capabilities.

For example, conventional software for interfacing with coupling devices is proprietary and is therefore not usable for existing standard software running on non-proprietary operating systems.

In an example of coupling device usage, communication software based on coupling devices requires each of the multiple operating systems to run a local queue manager, which adds extra overhead to the communication infrastructure. Implementations of interprocess communication with FIFO semantics according to the P0 SIX standard exist in modem operating systems (e.g. UNIX, Linux), however these implementations limit the communication to programs running in the same operating system instance.

SUMMARY OF THE INVENTION

In view of the foregoing and other exemplary problems, drawbacks, and disadvantages of the conventional methods and structures, an exemplary feature of the present invention is to provide a method for multiple operating systems to efficiently communicate via a coupling device.

Another exemplary feature of the present invention is a system including a coupling device and multiple operating systems which provide a POSIX compliant API for communication with FIFO semantics. Exemplarily, methods to deallocate FIFO's from a coupling device and to repair FIFO's on the coupling device after the crash of one of the connected operating systems may be provided.

The present invention provides a method of implementing a first-in, first out (FIFO) communication system including a plurality of operating systems and a coupling device, the coupling device including a plurality of queues, each operating system including an application programming interface configured to read from and write to the plurality of queues via the application programming interface using a standard POSIX FIFO semantics, the method including, initializing locks and data structures on the coupling device to represent POSIX FIFO's, executing a "mountO" function on one of the plurality of operating systems to mount a directory tree representing the queues in the coupling device into a directory tree of the one of the plurality of operating systems, executing one of an "open (OWRONLYONONBLOCK)" function and an "open (0 WRONLY)" function on the one of the plurality of operating systems to open one of the plurality of queues for writing, and executing a "write ()"function, including n bytes of data, on the one of the plurality of operating systems to write the n bytes of data to an entry at an end of the one of the plurality of queues after executing one of the "open (0 WR0NLY0_NONBL0CK)" function and the "open (0_WRONLY)" function, executing one of an "open (0_RDONLY0NONBL0CK)" function and an "open (0 RDONLY)" function on the one of the plurality of operating systems to open one of the plurality of queues for reading, executing a "read ( )" function on the one of the plurality of operating systems to command the application programming interface to read data from an entry at a beginning of the one of the plurality of queues after executing one of the "open (0 RD0NLYO_NONBL0CK)" function and the "open (ORDONLY)" function, executing a "close ( )" function on the one of the plurality of operating systems to close the one of the plurality of queues, executing an "unmount ( )" function on the one of the plurality of operating systems to unmount the directory tree representing the queues in the coupling device from the directory tree of the one of the plurality of operating systems, and repairing FIFO's on the coupling device after a crash of one of the connected operating systems and deallocating data structures representing POSIX FIFOs from the coupling device.

The "mountO", "open (0 RD0NLY0NONBL0CK)", "open (0_RDONLY)", "open (0WR0NLYONONBL0CK)", "open (0 WRONLY)", "write ()", "read ()", and "close ()", "umountQ" functions are exemplarily implemented as parts of the operating system kernels.

The "open (O_RDONLYO NONBLOCK)", "open (0 RDONLY)", "open (OWRONLYONONBLOCK)", "open (0 WRONLY)", "write ( )", "read ()", and "close (3", functions are implemented compliant to the POSIX standard.

The "wnteQ" flinction is exemplarily implemented such that it requires only a single coupling device operation for writing at most PIPE BUF bytes to a non-full FIFO.

The "readO" function is exemplarily implemented such that it requires only a single coupling device operation for reading into a read buffer of the at least PIPE BUF bytes from an non-empty FIFO white att other readers read into read buffers of the at teast PIPE BUF bytes.

Another exemplary embodiment of the present invention includes a computer readable medium tangibly embodying a program for executing the method set forth above.

One advantage of the present invention is that, exemplarily, the implementation of the write() function requires only a single coupling device operation (only one piece of communication between operating system and coupling device) for every up to PIPE BUF bytes to be written unless both the FIFO is full and it was opened with "open(WRONLY)," where PIPE BUF is a value defined in the POSIX standard.

Another advantage of the present invention is that, exemplarily, the imptementation of the read() function is such that it requires only a single coupling device operation if the read buffer is greater than or equal to PIPE BUF bytes, the FIFO is non empty and there is no contention with another reader that uses a read buffer smaller than PTPE_BUF bytes.

An additional advantage of the present invention is that, exemplarily, the implementation of the read() function ensures that there is no contention among readers that use read buffers that are each greater than or equal to PIPE BUF bytes.

An additional advantage of the present invention is that, exemplarily, the implementation of the write() function provides a means to safety send a data to a receiver without requiring an immediate acknowledgment by the receiver.

An additional advantage of the present invention is that, by providing a POSIX compliant API for communication via coupling devices, software designed to run multiple processes within one operating system such that these processes communicate via Unix F1FO's can now run distributed across multiple operating systems while communicating via coupling device based FIFO's. This exemplarily allows applications written to communicate within the same operating system to communicate across different nodes of a cluster without any change of the application thereby benefiting from the qualities of the coupling device.

An additional advantage of the present invention is that, by providing a POSIX standard compliant API to communicate via coupling devices increases the likeliness that software developers will accept to use coupling devices as a communication medium.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other exemplary purposes, aspects and advantages will be better understood from the following detailed description of an exemplary embodiment of the invention with reference to the drawings, in which: Figure 1 illustrates a system including multiple operating systems and a coupling device according to an exemplary embodiment of the invention; Figure 2 illustrates a coupling device of the system of Fig. 1; Figure 3 illustrates a queue sub area of the coupling device of Fig. 2; Figures 4a and 4b illustrate subcomponents of the queue sub area of Fig. 3; Figure 5 illustrates a subcomponent of the queue sub area of Fig. 3; and Figures 6, 7a, 7b, 8a, 8b, 9, 10, 1 la, 1 ib, 12, and 13a-13d illustrate an exemplary method of operating the system of Fig. 1.

Figure 14 illustrates a typical hardware configuration which may be used for implementing the computer system and method according to the exemplary aspects of the present invention; and Figure 15 illustrates a magnetic data storage diskette 1500 and CD-ROM 1502 to store the system 1.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS OF THE

INVENTION

Figs. 1-3, 4a, 4b, and 5 disclose an exemplary embodiment of system 1 according to an aspect of the present invention. System 1 may include coupling device 10 and a plurality of operating systems 2-1, 2-2, 2-3, 3-1, 3-2, 3-3. System 1 may be contained within one computer system or its components may be distributed across several computer systems. Each of coupling device 10 and plurality of operating systems 2-1, 2-2, 2-3, 3-1, 3-2, 3-3 may be any computer system or system component, for example, a server or a plurality of servers.

Referring to Figure 1 each operating system 2-x may include an application programming interface 2-x-1 and operating system 3-x may include application programming interface 3-x-1.

Referring to Figure 2, coupling device 0 may include queue area U. Queue area U may be a memory configured to represent a first-inlfirst-out (FIFO) file system. A HFO file system is a set of FIFO's. Queue area 12 may include cf_F1FO sb lock 13, FTFO file system meta data: cfFIFOsb 14, and a plurality of queue subareas 12-1, 12-2.. 12-x.

Exemplarily each queue subarea contains three lists or locks. Each queue subarea describes a FIFO. A FIFO signifies that the first entry written into a FIFO 12-x will be the first entry read from that FIFO 12-x.

Referring to Figure 3, each queue subarea 12-x may include openlclose lock: cf_open_lock 15, a list of systems that have opened the FIFO for reading: cf_read_open list 16, a list of systems that have opened the FIFO for writing: cf_write_open_list 17, cf_write_sentinel 19, list of data in FTFO: cf_data_list 18, and read lock: cf_read_lock 20.

List of systems that have opened the FIFO for reading: cf_read_open_list 16 may include a plurality of entries SY1:nl 16-1, SY2:n2 16-2... SYx:nx 16-x. As shown in Fig. 4a, in 16-x SYx may be a name of an operating system that has opened the FTFO for reading and nx may be the number of times SYx has the FIFO open for reading.

List of systems that have opened the FIFO for writing: cf_write_open_list 17 may include a plurality of entries SY1:nl 17-1, SY2:n2 17-2... SYx-nx 17-x. As shown in Fig. 4b, in 17-x SYx may be a name of an operating system that has opened the FIFO for writing and nx may be the number of times SYx has the FIFO open for writing.

Referring to Figures 3 and 5, the list of data in FIFO: cf_data_list 18 may include a plurality of data entries 18-la, 18-2a... 18-xa that each hold data each with a corresponding adjunct data entry 18-lb, 18-2b... 18-xb for metadata. Data entries 18-la, 18-2a... 18-xa may hold a maximal amount of data of PIPE BUF bytes. Adjunct data entry 1 8-lb, 18-2b... l8-xb may include start idx and end_idx which respectively determine the first and last valid byte of data in corresponding data entry 18-la, 18-2a... 18-xa. Referring to Figure 3, lists 16, 17 and 18 may be implemented as queues of a coupling device.

Referring again to Figures 1 and 2, in each operating system 2-x or 3-x, application programming interface 2-x-1 or 3-x-1 may be used to manage queue area 12. Executing functions from the application programming interface may result in communication between the operating system and the coupling device so as to manipulate data on the coupling device or to extract data from the coupling device. Exemplarily, these ifinctions, including a read, write, open, close, mount, or unmount command may be implemented to require only a single coupling device operation. The software for application programming interface 2-x-1 or 3-x- 1 may be written in any language, for example, C or Assembler and may be part of any operating system that implements POSIX file systems, for example Unix or Linux. For Unix and Linux operating systems the API is preferably implemented as a kernel module for a new file system type.

Before either a write or read operation is performed, queue area 12 and all of its subcomponents must be created in the memory of the coupling device. Queue area 12 may be created by a maintenance program which may be run from any operating system connected to coupling device 10, for example, any of operating systems 2-1, 2-2, 2-3, 3-1, 3-2, 3-3. The maintenance program may allocate and initialize all locks and data structures for queue area 12 as desired. The maintenance program may be also delete queue area 12 or any of its subcomponents when they are no longer needed. The maintenance program may also deal with crashes of operating systems 2-1, 2-2, 2-3, 3-1, 3-2, 3-3, which will be detailed below.

Figures 6, 7a, 7b, 8a, 8b, 9, 10, 1 la, 1 ib, 12, and 13a-13d disclose exemplary methods of reading data from and writing data to queue subareas 12-1, 12-2... 12-x using system 1 once queue subareas 12-1, 12-2... 12-x have been created. These methods exemplarily make up the application programming interface in 2-x-1.

Figure 6 illustrates exemplary methods to open a FIFO for either one of a reading and writing operation. Referring to Figure 6, in Step 20/30, an operating system, for example, operating system 2-1, mounts directory of FIFO's represented by the queue area 12 in the coupling device 10 by executing a POSIX "mount ()" function from application programming interface 2-1-1. All the functions executed on operating system 2-ito communicate with coupling device 10 are POSIX compliant so as to simplify usage by the operator. Executing the "mount ()" function causes the directory tree for queue area 12 in coupling device 10 including FIFO's represented by queue subareas 12-1, 12-2... 12-x to appear in the directory tree for operating system 2-1 as a standard file interface. Multiple operating systems 2-1, 2-2, 2-3, 3-1, 3-2, 3-3 may simultaneously have queue area 12 from coupling device 10 mounted thereto.

Then in Step 21, if operating system 2-1 needs to write to or anticipates it may need to write data to a particular queue subarea 12-1, 12-2... 12-x, for example, queue subarea 12-1, operating system 2-1 executes an OPEN function in application programming interface 2-1-1.

If operating system 2-1 is successful in opening queue subarea 12-1 for writing, the presence of operating system 2-1 is denoted in cf_write_open_list 17-1.

After operating system 2-1 opens queue subarea 12-1, in Step 22 operating system 2-1 executes a WRITE function from application programming interface 2-1-1 to place n bytes in one or more entries at the end of queue subarea 12-1. At this point, operating system 2-1 has the option of repeating Step 22 if more data is to be written to queue subarea 12-1.

Once all write operations have ended, in Step 23 operating system 2-1 executes a CLOSE function from application programming interface 2-1-1. At that point, application programming interface 2-1-1 closes access of operating system 2-1 to queue subarea 12-1 and denotes the departure of operating system 2-1 from queue subarea 12-1 in cf_write_open_list 17-1. At this point, operating system 2-1 has the option of proceeding back to Step 21 if more data is to be written to a queue subarea in queue area 12, or may proceed to Step 31 if operating system 2-1 desires to read data from a queue subarea in queue area 12.

In Step 31, if operating system 2-1 needs to read from or anticipates it may need to read data from a particular queue subarea 12-1, 12-2... 12-x, for example, queue subarea 12-1, operating system 2-1 executes an OPEN function from application programming interface 2-1-1. If operating system 2-1 is successful in opening queue subarea 12-1 for reading, the presence of operating system 2-1 is denoted in cf_read_open_list 16-1.

After operating system 2-1 opens queue subarea 12-1, in Step 32 operating system 2-1 executes a READ function to application programming interface 2-1-1 to read data from the beginning of queue subarea 12-1. Application programming interface 2-1-1 then read and deletes bytes from an entry at the beginning of queue area 12. If all bytes of the first entry are read then that entry will be deleted from queue subarea 12-1. At this point, operating system 2-1 has the option of repeating Step 32 if more data is to be read from queue subarea 12-1.

Once all read operations have ended, in Step 33 operating system 2-1 executes a CLOSE function from application programming interface 2-1-1. At that point, application programming interface 2-1-1 closes access of operating system 2-1 to queue subarea 12-1 and denotes the departure of operating system 2-1 from queue subarea 12-1 in cf_read_open_list 16-1. At this point, operating system 2-1 has the option of proceeding back to Step 31 if more data is to be read from a queue subarea in queue area 12, or may proceed to Step 21 if operating system 2-1 desires to write data to a queue subarea in queue area 12.

If all operations between operating system 2-1 and queue area 12 on coupling device 10 are completed, operating system 2-1 may issue a "umount ( )" function to coupling device 10 to disconnect the directory tree represented by queue area 12 on coupling device 10 including queue subareas 12-1, 12-2... 12-x from the directory tree of operating system 2-1 as set forth in Step 40.

Two exemplary versions of the OPEN function in Step 31 of Fig. 6 that may be executed by one of operating systems 2-1, 2-2, 2-3, 3-1, 3-2, 3-3, for example operating system 3-1, to application programming interface 3-1-1 to open one of queue subareas 12-1, 12-2... 12-x, for example queue subarea 12-1, for reading may be provided. An exemplary flowchart of "open (ORDONLY)" is set forth in Fig. 7a. An exemplary flowchart of "open (O_RDONLYO_NONBLOCK)" is set forth in Fig. 7b.

In Fig. 7a for the "open (0 RDONLY)" function, Step 31-la begins by operating system 3-1 determining the correct coupling device 10, queue area 12, and queue subarea 12-1, 12-2...

12-x to read data from, for example, queue subarea 12-1. If operating system 3-1 successfully locates coupling device 10, queue area 12, and queue subarea 12-1 in Step 31-ib, the process then proceeds to Step 31-id. Otherwise, the process returns with error at Step 31-ic.

In Step 31-ld, operating system 3-1 creates kernel data structures for the FIFO. API 3-1-1 then continuously attempts to lock cf_open_lock 15 of queue subarea 12-1 until it is successful. Once that occurs, API 3-1-1 updates cf_read_open_list 16 to reflect that operating system 3-1 has opened queue subarea 12-1 for reading, either for the first time or for another time, in the SYx:nx field. The process then proceeds to Step 31-le where API 3-1-1 determines whether cf_write_open_list 17 is empty (e.g., whether any of operating systems 2- 1, 2-2, 2-3, 3-1, 3-2, 3-3 has opened queue subarea 12-1 for writing).

If the answer is YES, the process proceeds to Step 31-lfwhere APT 3-1-1 releases cf_open_lock 15, waits for a period of time, and then again attempts to lock cf_open_lock 15 until it is successful. The process then goes back to Step 31-le.

If the answer is NO in Step 31-1 e, in Step 31-1 g API 3-1-1 sets cf_write_sentinel 19 to 1 and releases cf_open_lock 15. The process then goes to Step 31-1 h where a success indication is returned that queue subarea 12-1 is open for reading in blocking mode.

In Fig. 7b for the "open (0 RDONLYO_NONBLOCK)" function, Step 3 l-2a begins by operating system 3-1 determining the correct coupling device 10, queue area 12, and queue subarea 12-1, 12-2... 12-x to read data from, for example, queue subarea 12-1. If operating system 3-i successfully locates correct coupling device 10, queue area i2, and queue subarea 12-1 in Step 31-2b, the process proceeds to Step 31-2d. Otherwise, the process returns with an error at Step 31-2c.

In Step 31-2d, operating system 3-1 creates kernel data structures for the FIFO. API 3-1-1 then continuously attempts to lock cf_open_lock 15 of queue subarea 12-1 until it is successful. Once that occurs, API 3-1-1 updates cf_read_open_list 16 to reflect that operating system 3-1 has opened queue subarea 12-1 for reading, either for the first time or for another time, in the SYx:nx field. API 3-1-1 then sets cf_write_sentinel 19 to 1 and releases cf_open_lock 15. The process then goes to Step 31 -2e where a success indication is returned that queue subarea 12-1 is open for reading in non-blocking mode.

There are two versions of the OPEN function in Step 21 of Fig. 6 that may be executed by one of operating systems 2-1, 2-2, 2-3, 3-1, 3-2, 3-3, for example operating system 3-1, from APT 3-1-1 to open one of queue subareas 12-1, 12-2... 12-x, for example queue subarea 12-1, for writing. An exemplary flowchart of "open (0 WRONLY)" is set forth in Fig. 8a. An exemplary flowchart of "open (O_WRONLYO NONBLOCK)" is set forth in Fig. 8b.

In Fig. 8a for the "open (0 WRONLY)" function, Step 21-la begins by operating system 3-1 determining the correct coupling device 10, queue area 12, and queue subarea 12-1, 12-2...

12-x to write data from, for example, queue subarea 12-1. If operating system 3-1 successfully locates correct coupling device 10, queue area 12, and queue subarea 12-1 in Step 21-ib, the process proceeds to Step 21-id. Otherwise, the process returns with an error at Step 21-lc.

In Step 21-ld, operating system 3-1 creates kernel data structures for the FIFO. API 3-1-1 then continuously attempts to lock cf_open_lock 15 of queue subarea 12-1 until it is successful. Once that occurs, API 3-1-1 updates cf_write_open_list 17 to reflect that operating system 3-1 has opened queue subarea 12-1 for writing, either for the first time or for another time, in the SYx:nx field. The process then proceeds to Step 21-le where API 3-1-1 determines whether cf_read_open_list 16 is empty (e.g., whether any of operating systems 2- 1, 2-2, 2-3, 3-1, 3-2, 3-3 has opened queue subarea 12-1 for reading).

If the answer is YES, the process proceeds to Step 21-lfwhere API 3-1-1 releases cf_open_lock 15, waits for a period of time, and then again attempts to lock cf_open_lock 15 until it is successful. The process then goes back to Step 21-le.

If the answer is NO in Step 21-le, the process proceeds to Step 21-ig and releases cf_open_lock 15. The process then goes to Step 21-lh where a success indication is returned that queue subarea 12-1 is open for writing in blocking mode.

In Fig. 8b for the "open (0 WRONLYO_NONBLOCK)" function, Step 21-2a begins by operating system 3-1 determining the correct coupling device 10, queue area 12, and queue subarea 12-1, 12-2... 12-x to write data to, for example, queue subarea 12-1. If operating system 3-1 successfully locates correct coupling device 10, queue area 12, and queue subarea 12-1 in Step 21-2b, the process then moves to Step 21-2d. Otherwise, the process returns with error at Step 21-2c.

In Step 21-2d, operating system 3-1 creates kernel data structures for the FIFO. API 3-1-1 then continuously attempts to lock cf_open_lock 15 of queue subarea 12-1 until it is successful. Once that occurs, API 3-1-1 updates cf_write_open_list 17 to reflect that operating system 3-1 has opened queue subarea 12-1 for writing, either for the first time or for another time, in the SYx:nx field. API 3-1-1 then determines whether cf_read_open_list 16 is empty (e.g., whether any of operating systems 2-1, 2-2, 2-3, 3-1, 3-2, 3-3 has opened queue subarea 12-1 for reading).

If the answer is YES, API 3-1-1 proceeds to Step 21-2f, releases cf_open_lock 15, and an error indication is returned that queue subarea 12-1 is not open for writing.

If the answer is NO, API 3-1-1 proceeds to Step 21-2g, releases cf_open_lock 15, and a success indication is returned that queue subarea 12-1 is open for writing in non-blocking mode.

The CLOSE function in Step 33 for FIFO's opened with the "open (O_RDONLY)" or "open (ORDONLYONONBLOCK" is the same, and shown in Fig. 9. In Step 33-1, API 3-1-1 continuously attempts to lock cf_open_lock 15 of queue subarea 12-1 until it is successful.

Once that occurs, API 3-1-1 updates cf_read_open_list 16 to reflect that operating system 3-1 has closed queue subarea 12-1 for reading in the SYx:nx field. API 3-1-1 then determines whether cf_read_open_list 16 is empty.

If the answer is NO, in Step 33-4 API 3-1-1 releases cf_open_lock 15 and a success indication is returned by operating system 3-1 that queue subarea 12-1 is closed for reading.

If the answer is YES, in Step 33-3 API 3-1-1 set cf_write_sentinel 19 to 0. API 3-1-1 then proceeds to Step 33-4 as set forth above.

The CLOSE function in Step 23 for FIFO's opened with the "open (0 WRONLY)" or "open (O_WRONLYO_NONBLOCK)" is the same, and shown in Fig. 10. In Step 23-1, API 3-1-1 continuously attempts to lock cf_open_lock 15 of queue subarea 12-1 until it is successful.

Once that occurs, in Step 23-2 API 3-1-1 updates cf write open list 17 to reflect that operating system 3-1 has closed queue subarea 12-1 for writing in the SYx:nx field. In Step 23-3 API 3-1-1 releases cf_open_lock 15, and in Step 23-4 a success indication is returned by operating system 3-1 that queue subarea 12-1 is closed for writing.

There are two versions of the WRITE function in Step 22 of Fig. 6 that may be executed by one of operating systems 2-1, 2-2, 2-3, 3-1, 3-2, 3-3, for example operating system 3-1, from application programming interface 3-1-1 to write in one of queue subareas 12-1, 12-2... 12-x, for example queue subarea 12-1. An exemplary flowchart of a WRITE function for queue subarea 12-1 opened with "open (0 WRONLY)" is set forth in Fig. 11 a, and an exemplary flowchart of a WRITE function for queue subarea 12-1 opened with "open (O_WRONLYO_NONBLOCK)" is set forth in Fig. 1 lb. In Fig. lla for WRITE function for queue subarea 12-1 opened with "open (OWRONLY)", Step 22-la begins by operating system 3-1 taking a maximum of PIPE BUF bytes from its write buffer to be written to queue subarea 12-1 and in Step 22-lb add them in a new entry 18-xa with adjunct data 18-xb to the end of cf_data_list 18 in queue subarea 12-1 provided the cf_write_sentinel 17-1 equals 1 if cf_write_sentinel does not equal one nothing is added to queue subarea 12-1.

API 3-1-1 then checks in Step 22-lc if cf_write_sentinel 19 was equal to 0 in Step 22-lb.

If the answer is NO, the process then proceeds to Step 22-le.

If the answer is YES in Step 22-ic, then the process proceeds to Step 22-id where API 3-i-i returns with an error EPIPE and post signal SIGPIPE to the caller of the WRITE function.

In Step 22-ie, if cf_data_list i8 is was lull in Step 22-ib, the process proceeds back to Step 22-ib. If cf_data_list i8 was not full, the process proceeds to Step 22-if In Step 22-if, if the write buffer of the WRITE function is empty, API 3-i-i returns the number of all bytes written to the queue subareas i 2-i by this instance of the WRITE function. If the write buffer the WRITE function is not empty, the process proceeds back to Step 22-ia.

In Fig. ilb for WRITE function for queue subarea 12-i opened with "open (OWRONLYONONBLOCK)", Step 22-2a begins by operating system 3-i taking a maximum of PIPE_BUF bytes from its write buffer to be written to queue subarea i2-i and add them in a new entry i 8-xa with adjunct data i 8-xb to the end of cf_data_list 18 in queue subarea i 2-i provided the cf_write_sentinel i 7-i equals i, if cf_write_sentinel does not equal one nothing is added to queue subarea i 2-i.

API 3-i-i then checks in Step 22-2b if cf_write_sentinel i9 was equal to 0 in Step 22-2a.

If the answer is NO, the process then proceeds to Step 22-2d.

If the answer is YES in Step 22-2b, then the process proceeds to Step 22-2c where API 3-1-1 returns an error EPIPE and post signal SIGPIPE to the caller of the WRITE function.

In Step 22-2d, if cf_data_list i 8 was full in Step 22-2a, the process proceeds to Step 22-2e where API 3-i -1 determines whether any data has been written to the FIFO represented by queue subarea i2-i.

If the answer is NO in Step 22-2e, API 3-i-i returns an error EAGAIN signal in Step 22-2f If the answer is YES in Step 22-2e, API 3-i-i returns the number of all bytes written to the queue subarea 12-1 by this instance of the WRITE function in Step 22-2h.

In Step 22-2d, if cf data list 18 is not full, it is determined whether the write buffer of the WRITE function is empty in Step 22-2g.

If the answer is YES in Step 22-2g, API 3-1-1 returns the number of all bytes written to the queue subarea 12-1 by this instance of the WRITE function in Step 22-2h.

If the answer is NO in Step 22-2g, the process proceeds back to Step 22-2a.

Fig. 12 discloses various methods of reading data from a FIFO represented by a queue subarea 12-1 in Step 32 of Fig. 6 depending on which open function among "open (ORDONLY)" and "open (0 RDONLYO NONBLOCK)" is used, and the size of the read buffer of operating system 2-1, 2-2, 2-3, 3-1, 3-2, 3-3 which desires the data from queue subarea 12-1, for example operating system 2-1, relative to a maximum size PIPE BUF of the data that fits in a data entry 18-la, 18-lb... 1 8-lx of one of queue subareas 12-1, 12-2... 12-x of queue area 12. For exemplary purposes, operating system 2-1 will attempt to acquire data from queue area 12-1.

In Step 32-1, the first determination made is whether the size of the read buffer of operating system 2-1 is greater than or equal to PIPE_BUF.

If the answer is YES in Step 32-1, it is determined whether the FIFO in question was opened with the O_NONBLOCK option in Step 32-2. If the answer is NO in Step 32-1, it is determined whether the FIIFO in question was opened with the O_NONBLOCK option in Step 32-3.

If the answer is YES in Step 32-2, the process proceeds to Step 32-4, which is set forth in Fig. 13a. If the answer is NO in Step 32-2, the process proceeds to Step 32-5, which is set forth in Fig. 13b.

If the answer is YES in Step 32-3, the process proceeds to Step 3 2-6, which is set forth in Fig. 13c. If the answer is NO in Step 32-2, the process proceeds to Step 32-7, which is set forth in Fig. 13d.

Fig. 13a discloses an exemplary flowchart for a scenario where the FIFO was opened with the O_NONBLOCK option and the read buffer of the READ function is greater than or equal to PIPE BUF. Tn Step 32-4a, API 2-1-1 atomically reads and deletes the first entry 18-la together with first adjunct data 18-lb of cf_data_list 18 provided the read lock cf_read_lock 20 is equal to 0 otherwise the entry is neither read nor deleted. In the subsequent step 32-4b API 2-1 -1 determines if cf_read_lock 20 was equal to 0 in Step 32-4a.

If the answer is NO in Step 32-4b, the process cycles back to Step 32-4a.

If the answer is YES in Step 32-4b, the process proceeds to Step 32-4c.

Tn Step 32-4c, if it is determined that cf_data_list 18 was not empty in step 32-4a, the process proceeds to Step 32-4p where API 2-1-1 puts the valid bytes in read and deleted data entry 18-la in the read buffer of the READ function and returns the number of those valid bytes.

In Step 32-4c, if it is determined that cf_data_list 18 was empty in Step 32-4a, the process proceeds to Step 32-4d where API 2-1-1 continuously attempts to lock cf_open_lock 15 until it is successful. API 2-1 -1 then atomically reads and deletes the first entry 18-la together with first adjunct data 18-lb of cf_data_list 18 provided the read lock cf_read_lock 20 is equal to 0 otherwise the entry is neither read nor deleted. In the subsequent step 32-4f API 2-1-ldetermines if cf_read_lock 20 was equal to 0.

if the answer is NO in Step 32-4f, the process cycles back to Step 32-4e.

If the answer is YES in Step 32-4f, the process then proceeds to Step 32-4g.

In Step 32-4g, if it is determined that cf_data_list 18 was not empty in Step 32-4e, the process proceeds to Step 32-4h where API 2-1-1 releases cf_open_lock 15. The process then proceeds to Step 32-4p where API 2-1 -1 puts the valid bytes in read and deleted data entry 18-la to the read buffer of the READ function and returns the number of those valid bytes.

In Step 32-4g, if it is determined that cf data list 18 was not empty in Step 32-4e, the process proceeds to Step 32-4j where it is determined if cf write_open 17 is empty.

If the answer is YES in step 32-4j, the process proceeds to Step 32-4k where cf_open_lock 15 is released by APT 2-1-1, and then in Step 32-4n APT 2-1-1 returns an end-of-file.

If the answer is NO in step 32-4j, the process proceeds to Step 32-4m where cf_open_lock 15 is released by APT 11, and then in Step 32-4o API 2-1-1 returns an error EAGAIN.

Fig. 13b discloses an exemplary flowchart for a scenario where the FIFO was opened without the ONONBLOCK option and the read buffer of the READ function is greater than or equal to PIPE BUF. In Step 32-5a, API 2-1-1 atomically reads and deletes the first entry 18-la together with first adjunct data 18-lb of cf_data_list 18 provided the read lock cf_read_lock is equal to 0 otherwise the entry is neither read nor deleted. In the subsequent step 32-Sb APT 2-1-1 determines if cf_read_lock 20 was equal to 0 in Step 32-5a.

If the answer is NO in Step 32-Sb, the process proceeds back to Step 32-5a.

If the answer is YES in Step 32-Sb, in Step 32-Sc, if it is determined that cf_data_list 18 was not empty in Step 32-Sa, the process proceeds to Step 32-Sn where API 2-1-1 puts the bytes in read and deleted data entry 18-la in the read buffer the READ function and returns the number of those valid bytes.

In Step 32-Sc, if it is determined that cf_data_list 18 was empty, the process proceeds to Step 32-Sd where APT 2-1-1 continuously attempts to lock cf_open_lock 15 until it is successful.

API 2-1 -1 then atomically reads and deletes the first entry 18-la together with first adjunct data 18-lb of cf_data_list 18 provided the read lock cf_read_lock 20 is equal to 0 other wise the entry is neither read nor deleted. In the subsequent step 32-Sf APT 2-l-ldetermines if cf_read_lock 20 was equal to 0 in Step 32-Se.

If the answer is NO in Step 32-Sf the process cycles back to Step 32-Se.

If the answer is YES in Step 32-Sf, in Step 32-4g, it is determined whether cf_data_list 18 was empty in Step 32-Se.

Tf the answer is NO in step 32-Sg, the process proceeds to Step 32-Sm where API 2-1-1 releases cf_open_lock 15. The process then proceeds to Step 32-Sn where API 2-1-1 puts the bytes in read and deleted data entry 18-la to the read buffer of operating system 2-1 and returns the number of those valid bytes.

In Step 32-5g, if it is determined that cf_data_list 18 was empty in Step 32-5e, the process proceeds to Step 32-5h where it is determined if cf write open list 17 is empty.

If the answer is YES in step 32-5h, the process proceeds to Step 32-5j where cf_open_lock 15 is released by API 2-1-1, and then API 2-1-1 returns an end-of-file.

If the answer is NO in step 32-5h, the process proceeds to Step 32-4k where cf_open_lock 15 is released by API 2-1-1, and then proceeds back to Step 32-Sa.

Fig. 13d discloses an exemplary flowchart for a scenario where the HFO was opened without the ONONBLOCK option and the read buffer of the READ function is smaller than PIPEBUF. In Step 32-7a, API 2-1-1 atomically reads the first entry 18-la together with first adjunct data 18-lb of cf_data_list 18 provided the reservations of read lock cf_read_lock 20 by API 2-1-1 succeeds otherwise the entry is not read. In the subsequent step 32-7b API 2-1-1 determines if cf_read_lock 20 was successfully reserved by API 2-1-1 in Step 32-7a.

If the answer is NO in Step 32-7b, the process cycles back to Step 32-7a.

if the answer is YES in Step 32-7b, the process then proceeds to Step 32-7c.

In Step 32-7c, if it is determined that cf_data_list 18 was not empty in Step 32-7a, the process proceeds to Step 32-7n where it is determined whether all the valid bytes from data entry 18-la fit into the read buffer of the READ function.

If the answer is YES in Step 32-7n, all the valid bytes in data entry 18-la are copied to the read buffer of the READ function in Step 32-'7p. Then API 2-1-1 atomically both deletes data entry 18-la together with the adjunct data 18-lb from data list 18 and releases the read_lock 18.

if the answer is NO in Step 32-7n, as many valid bytes as fit into the read buffer of the READ function are copied from the beginning of data entry 18-la into the read buffer in Step 32-7o.

API 2-1-1 then atomically both updates adjunct entry 18-lb by marking those bytes read into the read buffer as invalid and releases cf_read_lock 15.

Both Steps 32-7o and 32-7p proceed to Step 32-7q where API 2-1-1 returns the number of bytes copied to the read buffer.

In Step 32-7c, if it is determined that cf_data_list 18 was empty in Step 32-7a, the process proceeds to Step 32-7d where API 2-1-1 continuously attempts to lock cf_open_lock 15 until it is successful. API 2-1 -1 then atomically reads the first entry 18-la together with first adjunct data 18-lb of cf_data_list 18 provided the reservations of read lock cf_read_lock 20 by API 2-1-1 succeeds otherwise the entry is not read. In the subsequent step 32-7f API 2-1-1 determines if cf_read_lock 20 was successfully reserved by APT 2-1-1 in Step 32-7e.

If the answer is NO in Step 32-7f, the process cycles back to Step 32-7e.

If the answer is YES in Step 32-7f, the process then proceeds to Step 32-7g.

In Step 32-7g, if it is determined that cf_data_list 18 was not empty in Step 32-7e, the process proceeds to Step 32-7m where cf_open_lock is released, and then proceeds to Step 32-7n.

In Step 32-7g, if it is determined that cf_data_list 18 was empty in Step 32-7e, the process proceeds to Step 32-7h where it is determined if cf_write_open_list 7 is empty.

If the answer is YES in Step 32-7h, APT 2-1-1 releases cf_read_lock 20, then releases cf_open_lock 15 and returns end-of-file.

If the answer is NO in Step 32-6h, API 2-1-1 releases cf_read_lock 20, then releases cf_open_lock 15 and cycles back to Step 32-7a.

Fig. 13c discloses an exemplary flowchart for a scenario where the FIFO was opened with the ONONBLOCK option and the read buffer of the READ function is smaller than PIPE BUF.

In Step 32-6a, API 2-1-1 atomically reads the first entry 18-la together with first adjunct data 18-lb of cf_data_list 18 provided the reservations of read lock cf_read_lock 20 by APT 2-1-1 succeeds otherwise the entry is not read. In the subsequent step 32-6b API 2-1-1 determines if cf_read_lock 20 was successfully reserved.

If the answer is NO in Step 32-6b, the process cycles back to Step 32-6a.

If the answer is YES in Step 32-6b, the process then proceeds to Step 32-6c.

In Step 32-6c, if it is determined that cf_data_list 18 was not empty in Step 32-6a, the process proceeds to Step 32-6n where it is determined whether all the valid bytes from data entry 18-la fit into the read buffer of the READ function.

If the answer is YES in Step 32-6n, all the valid bytes in data entry 18-la are copied to the read buffer of the READ function in Step 32-6o. Then API 2-1-1 atomically both deletes data entry 18-la together with the adjunct data 18-lb from data list 18 and releases the read_lock 18.

If the answer is NO in Step 32-6n, as many valid bytes as fit into the read buffer of the READ function are copied from data entry 18-la into the read buffer in Step 32-6q. API 2-1-1 then atomically both updates adjunct entry 18-lb by marking only those bytes read into the read buffer as invalid and releases cf_read_lock 15 in Step 32-6r.

Both Steps 32-6o and 32-6r proceed to Step 32-6p where APT 2-1-1 returns the number of bytes copied to the read buffer.

In Step 32-6c, if it is determined that cf_data_list 18 was empty in Step 32-6a, the process proceeds to Step 32-6d where API 2-1-1 continuously attempts to lock cf_open_lock 15 until it is successful. API 2-1 -1 then atomically reads the first entry 18-la together with first adjunct data 18-lb of cf_data_list 18 provided the reservations of read lock cf_read_lock 20 by API 2-1-1 succeeds otherwise the entry is not read. In the subsequent step 32-6f API 2-1-1 determines if cf_read_lock 20 was successfully reserved by API 2-1 -1 in Step 32-6e.

If the answer is NO in Step 32-6f the process cycles back to Step 32-6e.

If the answer is YES in Step 32-6f, the process then proceeds to Step 32-6g.

In Step 32-6g, if it is determined that cf_data_list 18 was not empty in Step 32-6e, the process proceeds to Step 32-6m where cf_open_lock is released, and then proceeds to Step 32-6n.

In Step 32-6g, if it is determined that cf_data_list 18 was empty in Step 32-6e, the process proceeds to Step 32-6h where it is determined if cf_writer_open_list 17 is empty.

If the answer is YES in Step 32-6h, API 2-1-1 releases cf_read_lock, then releases cf_open_lock 15 and returns end-of-file.

If the answer is NO in Step 32-6h, API 2-1-1 releases cf read lock,then releases cf_open_lock 15 and returns an error EAGAIN.

In various embodiments, one or more of operating systems 2-1, 2-2, 2-3, 3-1, 3-2, 3-3 may crash and thus cease to communicate with coupling device 10. In such a scenario, a maintenance program may "close ()" and/or delete all references to the crashed operating system 2-1, 2-2, 2-3, 3-1, 3-2, 3-3 from cf_open_read_list 16 and cf_open_write_list 17 and to release all locks cf_open_lock 15, cf_read_lock 20 reserved by the crashed operating system of any of queue subareas of 12-1, 12-2... 12-x. If as a result of deleting a reference to a crashed operating system the cf_read_open_list 16 becomes empty the cf_write_sentinel 19 must be set to 0. This may be particular important for cf_open_read_list 16 so as to prevent data from being written to queue subarea 12-1, 12-2... 12-x when the only operating system 2- 1,2-2,2-3,3-1,3-2,3-3 that has opened queue subarea 12-1, 12-2... 12-x forreading has crashed.

A tool to repair a cf fifo FS if a system SY has crashed while using a cf_fifo would exemplarily delete all entries of SY in cf_read_open_lists and cf_write open lists of a cffifo FS, unlock all locks held by SY in the cf fifo FS, and unregister SY from the queue area containing the cf_fifo FS.

Exemplarily, tools to create or delete a cf_fifo from a Cdev are provided. For example, one tool would deallocate a queue area describing a cf_fifo FS while another would create a cf_fifo on a Cdev. The tool to create the cf-fifo would exemplarily create a queue area on a CDev and allocates and initializes all locks and data structures needed to represent a cf_fifo FS, allocate and initialize all locks and data structures needed to represent as many fifos as indicated by an argument, and initialize data structures to contain initial attributes of the file system and fifos as indicated in arguments A kernel module implementing the new FS type cf fifo is exemplarily provided that would include a set of kernel data structures to control each cf fifo fifo in a mounted cf fifo FS, standard structures (e.g. Linux struct file) for each "opening" of a cf_fifo fifo FF in a mounted cffifo FS, standard structures (e.g. Linux struct mode) for each fifo in a mounted cf fifo FS, an extension to the mount() operation to mount a cf fifo FS described by a CDev and queue area identifier into the file hierarchy of the operating system, default file system and fifo attributes will we read from cf fifo sb, and a default file system and fifo attributes may be overwritten by arguments provided to mount.

A maintenance program to allocate a fifo file system with a certain number N of fifos on a coupling device may allocate data structures to store a queue area (see Figure 2) to store a file system super block lock(cf fifo sb lock) , meta data queue and N queue sub areas (see Figure 3). Exemplarily, the meta data may describe a name, the maximal size of the fifos in the fifo file system, ownership and access right information. The file system super block lock may be reserved during the allocation and any maintenance operation on the file system. It will be released when the allocation is finished. The queue subareas will be initialized to contain empty cf_read_open_list, cf_write_open_list and cf_data_list lists, the cf_open_lock and the cf_read_lock will be unreserved and the cf_write_sentinel will be set to 0. The record size of the data entries of the cf_write_list elements will be at least PIPE BUF bytes big.

A maintenance program to deallocate a fifo file system from a coupling device may deallocate all configuration and data needed to store the fifo file system from the coupling device.

Referring now to Fig. 14, system 1400 illustrates a typical hardware configuration which may be used for implementing the inventive system and method for buying and selling merchandise. The configuration has preferably at least one processor or central processing unit (CPU) 1410. The CPUs 1402 are interconnected via a system bus 1414 to a random access memory (RAM) 1414, read-only memory (ROM) 1416, input/output (I/O) adapter 1418 (for connecting peripheral devices such as disk units 1421 and tape drives 1440 to the bus 1414), user interface adapter 1422 (for connecting a keyboard 1424, mouse 1426, speaker 1428, microphone 1432, and/or other user interface device to the bus 1414), a communication adapter 1434 for connecting an information handling system to a data processing network, the internet, and Tntranet, a personal area network (PAN), etc., and a display adapter 1436 for connecting the bus 1414 to a display device 1438 and/or printer 1439. Further, an automated reader/scanner 1441 may be included. Such readers/scanners are commercially available from many sources.

Such a method may be implemented, for example, by operating a computer, as embodied by a digital data processing apparatus, to execute a sequence of machine-readable instructions.

These instructions may reside in various types of signal-bearing media.

Thus, this aspect of the present invention is directed to a programmed product, including signal-bearing media tangibly embodying a program of machine-readable instructions executable by a digital data processor to perform the above method.

Such a method may be implemented, for example, by operating the CPU 1410 to execute a sequence of machine-readable instructions. These instructions may reside in various types of signal bearing media.

Thus, this aspect of the present invention is directed to a programmed product, comprising signal-bearing media tangibly embodying a program of machine-readable instructions executable by a digital data processor incorporating the CPU 1410 and hardware above, to perform the method of the invention.

This signal-bearing media may include, for example, a RAM contained within the CPU 1410, as represented by the fast-access storage for example. Alternatively, the instructions may be contained in another signal-bearing media, such as a magnetic data storage diskette 1500 or CD-ROM 1502, (Fig. 15), directly or indirectly accessible by the CPU 1410.

Whether contained in the computer server/CPU 1410, or elsewhere, the instructions may be stored on a variety of machine-readable data storage media, such as DASD storage (e.g., a conventional "hard drive" or a RAID array), magnetic tape, electronic read-only memory (e.g., ROM, EPROM, or EEPROM), an optical storage device (e.g., CD-ROM, WORM, DVD, digital optical tape, etc.), paper "punch" cards, or other suitable signal-bearing media including transmission media such as digital and analog and communication links and wireless. In an illustrative embodiment of the invention, the machine-readable instructions may comprise software object code, complied from a language such as "C," etc. While the invention has been described in terms of several exemplary embodiments, those skilled in the art will recognize that the invention can be practised with modification within the spirit and scope of the appended claims. Further, it is noted that, Applicant's intent is to encompass equivalents of all claim elements, even if amended later during prosecution.

Claims (1)

1. CLAIMS1. A method of implementing a first-in, first out (FIFO) communication system comprising a plurality of operating systems and a coupling device, the coupling device including a plurality of queues, each operating system including an application programming interface configured to read from and write to the plurality of queues via the application programming interface using a standard POSIX FIFO semantics, the method comprising: initializing locks and data structures on the coupling device to represent POSIX FIFO's; executing a "mountQ" function on one of the plurality of operating systems to mount a directory tree representing the queues in the coupling device into a directory tree of the one of the plurality of operating systems; is executing one of an "open (0 WRONLY0N0NBL0CK)" function and an "open (0_WRONLY)" function on the one of the plurality of operating systems to open one of the plurality of queues for writing; executing a "write ()" function, including n bytes of data, on the one of the plurality of operating systems to write the n bytes of data to an entry at an end of the one of the plurality of queues after executing one of the "open (OWRONLYIONONBLOCK)" function and the "open (0 WRONLY)" function; executing one of an "open (0 RDONLY0N0NBL0CK)" function and an "open (ORDONLY)" function on the one of the plurality of operating systems to open one of the plurality of queues for reading; executing a "read ( )" function on the one of the plurality of operating systems to read data from an entry at a beginning of the one of the plurality of queues after executing one of the "open (0_RDONLYO NONBLOCK)" function and the "open (O_RDONLY)" function; executing a "close ( )" function on the one of the plurality of operating systems to close the one of the plurality of queues; executing an "unmount ( )" function on the one of the plurality of operating systems to unmount the directory tree representing the queues in the coupling device from the directory tree of the one of the plurality of operating systems; repairing FTFO's on the coupling device after a crash of one of the connected operating systems;and deallocating data structures representing POSIX FIFOs from the coupling device, wherein the "mountO", "open (0 RDONLYONONBLOCK)", "open (ORDONLY)", "open (0 WRONLY ONONBLOCK)", "open (0 WRONLY)", "write ( )", "read ( )", and "close Q", "unmountQ" functions are implemented as parts of the operating system kernels, wherein the "open (0 RD0NLYONONBL0CK)", "open (0 RDONLY)", "open (0WR0NLY0NONBL0CK)", "open (0 WRONLY)", "write ()", "read ()", and "close O" functions are implemented compliant to the POSIX standard, wherein the "writeO" function is implemented such that it requires only a single coupling device operation for writing at most PIPE BUF bytes to a non-full FIFO, and wherein the "readO" function is implemented such that it requires only a single coupling device operation for reading into a read buffer of said at least PIPE BUF bytes from an non-empty FTFO while all other readers read into read buffers of said at least PIPE BUF bytes.