One writer, multiple readers, shared data table concurrent access

[0002] 1. Field of the Invention

[0003] The invention relates to the field of computer system data access protection.

[0004] 2. Background Information

[0005] Collections of data called databases are well known. Computer systems which can be used by multiple users are also well known. Database programs provide fast and efficient access to records in a database. To properly handle the distribution and retrieval of the data, data processing systems often include database management programs. These programs provide easy access to database information.

[0006] One common configuration of a database is one that is made up of various tables with each table containing rows and columns of information. The information stored across one row in the table would make up one record and the fields of the record would be the columns in the table. In other words, the table would contain rows of individual records and columns of record fields. Because one record may contain more than one field of information, the information of the field would make up the columns of the database table. Other database configurations are found in the art.

[0007] Database management programs often must support multiple users and should enable each user to access the same table concurrently. However, when more than one user on a multi-user system attempts to access a database, problems may arise. If one user is reading from the database, while another user is writing to the database, the data integrity of the data read by the first user is suspect. If two users are attempting to write data to the database, what is actually written is unpredictable and so data integrity is suspect. To minimize these and other data integrity problems, locking schemes have been implemented, wherein only one user at a time was allowed to access the database.

[0008] Locking a database meant that, whenever a user was reading from or writing to the database, only that user was allowed to access that database, while all other users were locked out. Thus, the problem of one user writing data to a database while another prior user is reading the same data from the database was eliminated. The problem of two users simultaneously writing to a database was also eliminated.

[0009] However, locking created system bottlenecks which severely impacted overall system performance, even in a small system with a small number of users. A single user could monopolize a database by gaining access and holding it locked. Other users were forced to wait for access until that first single user released the lock on the database. After the first user released the lock, a second user was free to gain access to the database and monopolize it just as the first user had. That time spent idly waiting was unproductive, wasted and, therefore, impaired system performance. For a larger system with a large number of users attempting to access the same database, the effective result was the same regardless of whether a single user was monopolizing the database. That was because even if no single user attempted to monopolize a single database, the aggregate time spent by all of the users attempting to access the database meant that each user spent a significant amount of time idly waiting for a turn in accessing the database.

[0010] In order to address this locking problem and to improve multi-user system performance by reducing the amount of time each user spent waiting for the same database, locks were distinguished based on the type of user access to the database. Thus locks were distinguished as read locks or write locks. A user having a read lock merely prevented another user from writing to the database, while allowing other users to obtain read locks and, concurrently, to read from the same database. A user having a write lock excluded all access by other users until the user having the write lock released the write lock. A system having read locks and write locks to achieve concurrency is also known as “several readers and one writer” system.

[0011] The above-described practice of protecting shared data tables involves allowing either multiple concurrent readers of the data, or at most one writer with no readers. However, a problem with this practice is that changing the table (writing) can be expensive because it blocks readers during the updates. In a multi-processing environment with numerous CPUs (central processing units), modifying performance critical shared data tables can become a bottleneck adversely affecting system performance.

[0012] Therefore, data access could be made more efficient and the bottleneck problems in the prior art overcome by an improved data access method.

[0013] It is, therefore, a principal object of the invention to provide a method for a one writer, multiple readers, shared data table concurrent access.

[0014] It is another object of the invention to provide a method and apparatus that solves the above mentioned problems so that one writer and multiple readers, can share a data table through concurrent access.

[0015] These and other objects of the present invention are accomplished by the method and apparatus disclosed herein.

[0016] According to an aspect of the invention, at most one writer is allowed to be updating a shared data table while multiple readers are using the same table.

[0017] According to an aspect of the invention, there are three data elements used. The first of these is a serialization mechanism, e.g., a semaphore (in the case of an IBM AS/400, an “SLIC QuGate object”). This mechanism is used to ensure at most one writer is modifying the shared data. Readers do not use this serialization at all. The second of these is a table/array of elements. Each element of the table must be able to be updated atomically by a processor with a load or store instruction. The third of these is an atomic, integer counter that indicates how many shared data elements are contained in the table.

[0018] According to an aspect of the invention, inserting a new element into the shared unsorted data table by a writer includes locking the table, wherein other writers are prevented from writing to the table, putting the new element at the end of the table, incrementing the counter, thereby making the new element visible to all readers, and unlocking the table.

[0019] According to an aspect of the invention, removing an element at a position in the shared unsorted data table by a writer includes locking the table, copying the table so that the element to be removed is at the end of the table, decrementing the counter, and unlocking the table.

[0020] According to an aspect of the invention, reading from the shared data table by a reader includes looping through all elements of the table, loading and caching each element of the table, and read-only processing each element of the table.

[0021] These and other aspects of the invention will become apparent from the detailed description set forth below.

[0022] FIGS. 1a, 1band 1cillustrate three state diagrams for adding a new element “Z” to a table that already contains “N” elements according to an exemplary embodiment of the present invention.

[0023] FIGS. 2a, 2band 2cillustrate three state diagrams for removing an element “H” located at position “I” in the table containing “N” elements according to an exemplary embodiment of the invention.

[0024] FIG. 3 illustrates a flow chart according to an exemplary embodiment of the invention.

[0025] FIG. 4 illustrates a system according to an exemplary embodiment of the invention.

[0026] The invention will now be described in more detail by way of example with reference to the embodiment(s) shown in the accompanying figures. It should be kept in mind that the following described embodiment(s) is/are only presented by way of example and should not be construed as limiting the inventive concept to any particular physical configuration.

[0027] There are three important data elements for the design:

[0028] (1) A serialization mechanism (403), e.g., a semaphore (in the case of an IBM AS/400, an “SLIC QuGate object”). This mechanism is used to ensure at most one writer is modifying the shared data. Readers do not use this serialization at all.

[0029] (2) A table/array of elements (shown in memory 402). Each element of the table must be able to be updated atomically by a processor (e.g., on the AS/400 an 8-byte pointer or 64-bit integer on an 8-byte boundary) with a load or store instruction.

[0030] (3) An atomic, integer counter (404) that indicates how many shared data elements are contained in the table.

[0031] FIGS. 1a, 1band 1cillustrate three state diagrams for adding a new element “Z” to a table that already contains “N” elements according to an exemplary embodiment of the present invention. In FIG. 1a, the state of the counter and the data table are shown before the operation has begun. It is assumed that the data table has additional entries beyond the end to accommodate the new entry. In FIG. 1b, the state of the table and counter are shown after element “Z” has been appended to the end of the table. In FIG. 1c, the state of the counter (incremented) and the data table are shown atomically updated with the new table size. Element “Z” is now visible to all readers. This is what the data looks like after the operation completes. During the update process, all concurrent readers will only see the above three states, due to atomicity requirements.

[0032] FIGS. 2a, 2band 2cillustrate three state diagrams for removing an element “H” located at position “I” in the table containing “N” elements according to an exemplary embodiment of the invention. In FIG. 2a, the state of the counter and the data table are shown before the operation has begun. In FIG. 2b, the last element “Z” is copied into location “I” that was occupied by element “H”. Element “Z” is now a duplicate. In FIG. 2c, the state of the counter (decremented) and the data table is shown after the operation has compeleted. The second copy of “Z” is removed from the visibility of readers by decrementing the counter. During the update process, all concurrent readers will only see the above three states, due to the atomicity requirements.

[0033] For the following algorithms, assume these variables are:

[0034] GATE Writer serialization mechanism, allowing at most one holder of the lock

[0035] N Number of elements currently in the shared data table

[0036] TABLE An array of elements, index is 0-based

[0037] The following is an exemplary algorithm for inserting a new element (ELEMENT) into the shared data table:

[0038] GATE.lock( ) //prevent other writers

[0039] TABLE[N]=ELEMENT //put the new element at the end

[0040] N=N+1//make the element visible to all readers

[0041] GATE.unlock( ) //release writer lock

[0042] The following is an exemplary algorithm for removing an element at a position (I) in the table:

[0043] GATE.lock( ) //prevent other writers

[0044] TABLE[I]=TABLE[N−1]//duplicate last element into removal position

[0045] N=N−1//delete duplicate now at the end

[0046] GATE.unlock( ) //release writer lock

[0047] The following is an exemplary algorithm for a reader of the table (no locking), who needs to process every element:

[0048] for I=0 to N−1//loop thru all elements in table

[0049] ELEMENT=TABLE[I]//atomically load and cache an element

[0050] process(ELEMENT) //do read-only processing with the element end for

[0051] The above exemplary algorithms show insertion and removal from an unsorted table where order does not matter. If an ordered, sorted table is required by an application, then the above algorithms can be easily extended, as would be readily apparent to one skilled in the art. Such modifications are not listed here because they are not necessary for a complete understanding of the invention.

[0052] The order of statements executed in the above algorithms is important, and must occur in the sequence listed so as to be visible to all processors on the system before a subsequent statement is executed.

[0053] There are some very important assumptions that must be true before the algorithms should be used by an application:

[0054] (1) Updates to the table are less frequent than readers.

[0055] (2) Processing of elements already in the table is not 100% required. Because of the way the algorithms work, there is not an absolute guarantee that an element stored in the table will be visible to a reader during an update.

[0056] (3) The application can tolerate having the same element appear more than once in the table for a reader during an update. The removal algorithm hinges on being able to duplicate valid entries in the table before removal actually occurs.

[0057] (4) The requirements above for having an atomic counter and table elements is necessary for eliminating the possibility of reading a variable and getting corrupted values (e.g., half old, half new).

[0058] (5) After removing an element from the table, it is possible that readers active during the removal could still be processing the element, The application must therefore not invalidate the removed element immediately after unlocking the writer's gate.

[0059] As long as the application can tolerate these five conditions, the exemplary algorithms according to the invention can improve system performance and break performance bottlenecks.

[0060] FIG. 3 illustrates a flow chart of process flow according to an exemplary embodiment of the invention. In block 301, the process flow for inserting a new element into a shared unsorted data table by a writer is illustrated. This process includes four steps: (1) lock the table preventing other writers from writing to the table; (2) put a new element at the end of the table; (3) increment the counter making the new element visible to all readers; and (4) unlock the table.

[0061] In block 302, the process flow for the removal of an element in a shared unsorted data table is illustrated. This process includes four steps: (1) lock the table preventing other writers from writing to the table; (2) copy the table so that the element to be removed is at the end of the table; (3) decrement the counter; and (4) unlock the table.

[0062] In block 303, the process flow for reading from a shared data table is illustrated. This process includes three steps: (1) loop through all the elements of the table; (2) load and cache each element of the table; and (3) read-only process each element of the table.

[0063] FIG. 4 illustrates a system 400, having a processor 401, memory 402, a serialization mechanism 403 and an atomic integer counter 404, according to an exemplary embodiment of the invention. The invention involves algorithms and assumptions that allow at most one writer to be updating a shared data table while multiple readers are using the same table.

[0064] The solution according to the invention differs from others in that reading shared data does not stop when doing updates to the shared data. A performance penalty for readers is not incurred by needing to execute the seize and release code to obtain a shared lock, reducing the instruction path length for “hot” paths in the system. Also, some forms of locking in operating systems require an application's data to be resident in main storage so as not to cause page faults during the time that the lock is being held. By eliminating the shared reader lock, the faultless requirement has been eliminated (in some cases), which further reduces path length and working set size of an application.

[0065] The invention has applicability in, for example, the IBM Gigabit Ethernet Adapter (2743) on the IBM AS/400. The device driver in the OS/400 operating system uses the algorithm according to the invention for mapping incoming network packets to clients interested in receiving particular kinds of packets. The device driver thus enables a client to be added/removed from this table without disrupting the incoming flow of packets needing to be routed. Performance is important to this adapter, and hence the application of this invention is an advantage for the card.

[0066] Because no locking for readers of the table is necessary, the present invention also removes requirements for pinning storage and obtaining/releasing spin locks, all of which would hurt the code path lengths for servicing the network packets. This particular application of the algorithm meets all assumptions listed above, because the device driver has the luxury of “dropping” incoming network packets at its discretion.

[0067] The invention also has applicability other adapters, such as adapters for providing multiple connections to the same logical direct access storage device (DASD—disk drive). The DASD router would use the algorithm according to the invention to enable the different connection paths to be added/removed to the router's table without disrupting the flow of DASD commands with the system. Similar to the Gigabit Ethernet Adapter implementation mentioned above, there will be no requirements for locking, so routing can be done efficiently from an interrupt handler.

[0068] The invention may be embodied as a computer program product. A computer program product includes a recording medium, such as a floppy disk, a high-capacity read only memory in the form of an optically read compact disc or CD-ROM, a tape, a transmission type media, such as a digital or analog communications link, or a similar computer program product.

[0069] It will be apparent to one skilled in the art that the manner of making and using the claimed invention has been adequately disclosed in the above-written description of the preferred embodiment(s) taken together with the drawings.

[0070] It will be understood that the above described preferred embodiment(s) of the present invention are susceptible to various modifications, changes, and adaptations, and the same are intended to be comprehended within the meaning and range of equivalents of the appended claims.

[0071] Further, although a number of equivalent components may have been mentioned herein which could be used in place of the components illustrated and described with reference to the preferred embodiment(s), this is not meant to be an exhaustive treatment of all the possible equivalents, nor to limit the invention defined by the claims to any particular equivalent or combination thereof. A person skilled in the art would realize that there may be other equivalent components presently known, or to be developed, which could be used within the spirit and scope of the invention defined by the claims.