US5481706A - System and method for creating thread-safe shared libraries - Google Patents

System and method for creating thread-safe shared libraries Download PDF

Info

Publication number
US5481706A
US5481706A US08/143,586 US14358693A US5481706A US 5481706 A US5481706 A US 5481706A US 14358693 A US14358693 A US 14358693A US 5481706 A US5481706 A US 5481706A
Authority
US
United States
Prior art keywords
function
pointer
wrapper
descriptor
function descriptor
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.)
Expired - Fee Related
Application number
US08/143,586
Inventor
Jeffrey S. Peek
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 US08/143,586 priority Critical patent/US5481706A/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: PEEK, JEFFREY S.
Application granted granted Critical
Publication of US5481706A publication Critical patent/US5481706A/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR 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

Definitions

  • This invention relates to systems and methods for managing shared resources in a computer system, and, more particularly, to shared resource management techniques in multithread environments.
  • SMP symmetric multiprocessor
  • thread in a general sense refers merely to a simple execution path through application software and the kernel of an operating system executing with the computer. As is also well understood in the art, it is commonplace for multiple such threads to be allowed per a single process image.
  • locks or “mutexes”. It is typical in modern computing systems to have critical sections of code or shared data structures such as in shared libraries whose integrity is extremely important to the correct operation of the system. Such locks/mutexes are devices employed in software (and hardware) to "serialize" access to these critical sections of code and/or shared data structures.
  • Blocking locks are of the form which cause a thread requesting the lock to cease being executable, e.g. to go to "sleep” as the term is employed in the art, if the lock is currently held by another thread.
  • Spin locks in contrast, do not put waiting threads to "sleep”, but rather, the waiting threads execute a spin loop, and thus repeatedly continue to request the lock until it is freed by the current thread "owner”.
  • Blocking locks are typically used for large critical sections of code or if the operating system kernel must differentiate between threads requiring data structure read-only capability and threads requiring the capability to modify the data structure(s). This latter read-write type lock may be found implemented, for example, in the current OSF/1 operating system release of the Open Software Foundation (OSF).
  • OSF Open Software Foundation
  • code being multithread-safe.
  • Such code is considered to be thread/MP-safe if multiple execution threads contending for the same resource or routine are serialized such that data integrity is ensured for all such threads.
  • One way of effecting this is by means of the aforementioned locks.
  • routines in such shared libraries do not require any form of hereinbefore noted serialization with respect to other routines in the library or multiple callers of the same routine. There is thus no problem with respect to shared or global data structures requiring use of locks or mutexes to prevent conception.
  • FIG. 1 is a schematic diagram of the structural components of a representative multithreaded computer system which may advantageously employ the computer system;
  • FIG. 2 is a more detailed illustration of a portion of the system of FIG. 1, depicting aspects of the shared resource components of FIG. 1;
  • FIG. 3 is a flow diagram illustrating the method for creating thread-safe libraries in accordance with the invention.
  • FIG. 4 is a flow diagram illustrating the thread-safe usage of shared libraries in accordance with the invention.
  • Libraries for use in a multithreaded computer environment which must be thread-safe and cannot be recoded are identified. Such libraries, after identification, are repackaged. Export routines for such libraries will thereby acquire a front end which effects several steps. First a write-exclusive lock for a particular called function of one of the libraries is generically acquired. A call is then made to the underlying function whose name has been remapped. Upon return from the real routine, the write-exclusive lock is unlocked and a return to the user is executed.
  • the system and method ensure correct functioning and integrity of the identified library functions accessible by multiple threads, as well as providing for creation of multithread-safe shared libraries without necessitating extensive library source modifications.
  • shared library functions not to be modified are identified and an export list of external functions extracted.
  • Function descriptors corresponding to each function are saved, and a wrapper generated for each function with a global lock and further having a corresponding one of the saved function descriptors.
  • Modified function descriptors are created for each function descriptor, each having an address of a corresponding wrapper entry point.
  • the table of contents to the shared library is modified so that a pointer is returned in response to a function call to the modified function descriptor rather than to the original function descriptor.
  • the corresponding wrapper to which the modified function descriptor pointer points includes, in the copy of the function descriptor contained therein, a pointer to the same function as the original function descriptor. This pointer invokes a lock on the function, whereupon the function code executes and issues a return, whereupon the lock is released.
  • the pointer in the copy of the function descriptor in the wrapper is identical to that of the original function descriptor.
  • a call is issued to execute a function of a shared library.
  • a pointer is retrieved from a table of contents of the shared library in response to the function call pointing to a modified function descriptor.
  • a pointer is retrieved from the modified function descriptor, in turn pointing to a wrapper corresponding to the function.
  • the wrapper contains a substantial copy of the original function descriptor, and, in particular, includes the same pointer as the original function descriptor to the executable function code.
  • this pointer causes execution of a lock on the function and subsequent execution of the function itself.
  • the wrapper code releases the lock and returns control for invocation of a next thread and corresponding function.
  • Wrappers are provided for each externalized function of the shared library whereby, in combination, they effect a wrapper around the executable shared library code. In this manner, due to the lock invoked when wrapper code corresponding to a given function is executed, the function is thereby made thread-safe. Data associated with the function thus may not be corrupted by a call by a subsequent thread, and the memory associated with the data is not released until the lock is released.
  • FIG. 1 depicts a multithread computer system with multiple processes sharing a shared library in accordance with the prior art. Accordingly, multiple processes A and B as shown are reference numerals 10, 12, respectively, and a shared library 14. It will be recalled from the foregoing that in single threaded process models of the prior art, corrupting library data was not a problem since a process would have its own copy of data, such as the copy of data 24 shown at reference numeral 20 or 22. A given process thus did not have access to the data 24 of the shared library 14 and only one thread, such as thread 1 shown at reference numeral 16 of process A, was permitted to access the copy 20 of the data at a given time.
  • the conventional way to access data 24 in a shared library 14 is through routines or code 23 provided by the shared library 14.
  • This code 23 will change shared library data 24 and generate pointers and the like thereby managing the data copies 20 and 24 with local and global variables, tables, hashing queues, and the like.
  • the multiple processes such as process A and B usually do not access the data 24, but rather go through the shared library routines of code 23, which duplicate the data 24 of the shared library and pass back information to respective processes based upon what the shared library code 23 did during such management.
  • the data from the shared library must thus be unique per process, e.g. a pristine copy of the data 24 must be provided as in copies 20 and 22 to each respective process 10, 12, whereby the multiple processes and threads will not corrupt the data 24 of the shared library 14 itself.
  • the routine or function call generated from the shared library code 23 will indicate that it is using a piece of data 24 for some working storage space. In these instances it will pass back an exact address of the data 24 in the shared library 14 to the calling thread from the particular process.
  • One approach is to rewrite the entirety of the functions of a library such as the aforementioned printf as well as its corresponding underlying routines to be thread-safe. This entails allocating unique portions of data storage such as at reference numeral 20, so that when a thread 17 calls a given function, such as printf or malloc, the thread of the function will use a different section of memory than that employed by a prior thread calling the same function.
  • Yet another approach is to provide a lock on the global data area of the particular function such as printf or malloc.
  • there are differing ways to make library routines thread-safe such as providing locks, having the functions pass the data area, utilizing a unique data area, having the function lock and unlock a common data area and provide returns giving the status of the lock.
  • all of these approaches require extra work and coding such as recoding the actual library functions as previously mentioned in a manner to render them thread-safe.
  • the solution essentially entails placing a wrapper around the code 23 of the shared library 14 (rather than the data 24) in a manner to be detailed.
  • Library functions in a given shared library have corresponding routines and function names which the given shared library "exports", i.e. which are available to an end user or application to call.
  • a representative such export list for shared library 14 is shown at reference numeral 26 of FIG. 1. It is conventional that when applications are built, the application is able to locate a symbol in corresponding function code of a given shared library because of the export list 26 providing the information of what the external function calls are which are available outside the shared library for use by an application. An example of such an entry in the export list would be the aforementioned printf or malloc external interface function names. More particularly, it is conventional to have a library file such as lib.exp as part of the shared library which is simply an ASCII file or string of all symbols exported from the shared library (such as malloc, free, printf . . . ).
  • the concept of the invention entails, in part, employing this export list of all exported function names from a given library and placing "wrappers" around each such function.
  • a wrapper is simply code extending around the instantiation of the call of the given corresponding function. If, for example, a thread calls a malloc function, in providing a "wrapper" for the particular function, this simply means placing another malloc (e.g. the wrapper) on top of the pre-existing function call such as malloc and renaming the underlying one.
  • the wrappered underlying version of malloc is called from the wrapper on top of the renamed underlying version.
  • a wrapper will be seen to be an individual piece of code placed around a corresponding individual function call or routine which is exported from the shared library.
  • the invention thereby protects all the function calls within the shared library from each other (e.g. separate calls to different functions from different multiple threads attempting to use the same data area) and further protects the calls from themselves (e.g. multiple calls from multiple threads to the same function such as printf, attempting to use again, the same data area for both such calls).
  • the aforementioned locks associated with the individual wrappers for each function will in actuality be the same global lock which each function will sequentially obtain at a given time upon execution of its corresponding wrapper code.
  • this global lock will prevent malloc from potentially overriding or otherwise corrupting the data area currently being employed by printf inasmuch as printf will acquire the lock, thus locking out malloc from corrupting that area until printf frees the lock.
  • all wrappers will obtain the same lock providing for relatively coarse serialization but nevertheless effecting the objects of the invention in preventing data corruption.
  • wrapper code for a given function when invoked, the same lock will be locked no matter what the routine is that is being called through the particular wrapper function.
  • the real code of the routine will then be called and executed, whereupon after a return is received from the routine, the wrapper's lock is unlocked, thereby freeing the data area for use by a call from a subsequent thread.
  • the library may thus be thought of as being thread-safe by means of this collection of wrappers.
  • wrappers there are instances wherein the actual library functions themselves simply cannot be recoded individually to provide a similar thread-safe characteristic.
  • an end user may have received an application shipped with a prior version of an operating system who now wants to run the application on a new version of the operating system but does not have access to the source code, does not want to repurchase it or have the vendor re-port it.
  • the end user even if he otherwise had the resources to recode the functions, could not do so without access to the source to recode the shared libraries or application.
  • wrappers by provision for the aforesaid wrappers, there is, in a limited sense, a necessity to nevertheless modify the shared library code.
  • the internal functions (binary or source code) need not themselves be recoded or altered.
  • the reshaping or modification of the shared library may be thought of as actually essentially occurring on top of or on the outer portion of the shared library, giving rise to the notion of a collection of "wrappers" around the code 23 of FIG. 1.
  • the "old" binary of the shared library prior to rendering it thread-safe in accordance with the invention may be saved off.
  • the initial build of the shared library will include creation of the aforementioned export list 26.
  • this export list is then extracted from the shared library, yielding a list of all the exported symbols, e.g. externalizing function call names in the shared library. They are then essentially renamed whereby an identical function either before or after modifications in accordance with invention will nevertheless be executed by the same call.
  • the identical function name will essentially invoke a pointer in a table of contents not to the old function descriptor existing prior to the modifications of the invention, but rather to a new function descriptor which, in turn, contains a pointer to the wrapper code corresponding to the function thus called.
  • FIG. 2 an explanation will be provided of the functional blocks depicted therein implementing the invention.
  • the export list 26 of FIG. 1 has been previously generated as a part of the prior shared library and is extracted therefrom. It is conventionally simply in ASCII format inside the shared library, and the extraction comprises locating it in the memory of the shared library, e.g. where all the names of exported functions corresponding to the shared library exist (e.g. those externalized by the library and accessible by the user).
  • each function such as "foo" in a given library has an associated function call 28 with a corresponding associated entry point in a table of contents 30.
  • This is essentially a pointer or address of an entry point, e.g. in the example under consideration a descriptor address 34 of the foo function which points to a function descriptor 32.
  • the function descriptor in conventional operation, contains the address of the entry point, 42, of the corresponding function or routine, e.g. the foo code 50. In this manner, accessing the function descriptor 32 by means of the foo call 28 will cause a pointer 48 to be invoked to the foo code 50 whereupon the desired library routine or foo code will execute.
  • the function descriptor 32 will also, conventionally, contain the address and memory, 44, of the table of contents 30, as well as data 46. Typically, also, one such table of contents 30 exists per shared library 14. In essence, in order to rename the function as previously described, this simply entails changing the symbol and storing off the function pointer. More particularly, a new function descriptor 38 is created, and the descriptor address 34 of the table of contents 30 is modified to point to this new function descriptor as shown by the arrow 40.
  • the table of contents 30, and, more particularly, the particular function's descriptor address 34 will now cause a pointing to the new or modified function descriptor 38 shown by arrow 40, rather than to the prior function descriptor 32 shown by the dotted arrow 36.
  • the entry point of this new or modified function descriptor 38 is actually what is replaced into the address 34 of the table of contents in place of that or the prior function descriptor 32.
  • this new function descriptor 38 in comparison with the function descriptor 32, will be seen to be essentially a copy of the prior function descriptor 32, containing the same address of table of contents 54, and data 56.
  • the significant difference between the two descriptors is that in the case of the address of the entry point, whereas the address or re-entry point 42 of the function descriptor 32 pointed to the actual routine code 50, the address of the modified function descriptor 38 shown at reference numeral 52 is now modified to be the address of the wrapper's entry point for the wrapper code 62.
  • the function descriptor 38 is invoked, whereupon the address of the wrapper's entry point 52 is, in turn, utilized to effect the pointer 58 to wrapper code 62.
  • the wrapper code 62 for each function 28 will include code necessary to invoke the locking and unlocking of the previously described global lock, shown in the wrapper code as lock 68 and unlock 72.
  • lock 68 and unlock 72 code necessary to invoke the locking and unlocking of the previously described global lock.
  • the wrapper code 62 is invoked by use of the pointer 58, the lock is locked by means of the execution of the lock code 68, whereupon the function descriptor 70 of the wrapper code 62 is employed.
  • this function descriptor 70 is essentially identical to that of the prior function descriptor 32. More particularly and more importantly, however, the address of the entry point 42 in the function descriptor 32 is identical to that of the function descriptor 70.
  • a return (shown as reference numeral 66) to the wrapper code 62 thereafter causes invocation of unlock code 72 to free the lock on the address space previously being utilized by execution of the particular library function. After this unlocking, this effects a return 60 to, ultimately, permit a function call by a next thread wherein the previous process is repeated.
  • the next call from a next thread sequentially is presented, in like manner, it will result in a pointer from the table of contents 30 to its corresponding function descriptor (which will differ for each of the functions in the library), in which case the previously described functions will again be replicated to cause execution of the actual library routine corresponding to this new function call from the next thread.
  • each wrapper code module 62 corresponds to one of the function descriptors 32, a corresponding one of the function descriptors 38, and a corresponding function in the shared library.
  • the table of contents 30 is modified and, more particularly, the function's entry in the table of contents is modified to now point to the new function descriptor 38.
  • wrapper code 62 When the user binds the new library, the table of contents is modified to call ultimately these wrapper routines (represented by wrapper code 62) and not the "old" or prior function descriptor 32 and routine code. If the latter were to happen, it will be readily apparent that the library function 50 would not be thread-safe inasmuch as no lock would have been provided. A subsequent function call from a next thread could then destroy data integrity. However, in accordance with the invention, the wrapper code 62 causes obtaining of the lock and calling of the actual underlying function previously in the library which is thus protected.
  • Rebuilding of the prior shared library essentially entails, in addition to creating the new function descriptors 38 and wrapper code 62, modifying the table of contents 30 to point to these new functions descriptors 38. Also, the "renaming" of the old modules (such as foo code 50) really simply entails changing how they are accessed. Now, they are accessed actually by invoking the wrapper code 62. It will be appreciated from the foregoing that path length has thus been increased arising from the addition of the wrapper code 62, the lock and unlock functions, and the extra function call (e.g. calling of the renamed function and the calling of the actual function itself). However, the effecting of a thread-safe shared library has thus nevertheless been implemented affording the other benefits not present in prior art approaches.
  • FIG. 3 a flow diagram is shown illustrating the steps of creating the thread-safe library.
  • the process is entered at 74, whereupon shared library functions which are not to be re-coded are identified, 76.
  • an export list is extracted listing all the symbols of the corresponding functions in the given library or libraries which are not to be recoded.
  • the prior function descriptors corresponding to each function are saved off, 80.
  • a wrapper is generated for each such function which will activate and deactivate a global lock, 82.
  • a modified function descriptor for each prior function descriptor is constructed with an address or pointer to a corresponding wrapper entry point for the wrapper generated at reference numeral 82.
  • This step of creating the modified function descriptors is shown at reference numeral 84.
  • the table of content(s) is then modified to the shared library or libraries so that a pointer is now returned, in response to a given function call, to a corresponding modified function descriptor rather than the original function descriptor.
  • FIG. 4 a simplified flow diagram is shown of the sequence of operation in accordance with the invention whereby a function from a multithread process is invoked (whereby the corresponding library routine is executed in a thread-safe manner in accordance with the invention).
  • the sequence is entered at 90 whereupon a function call is issued to execute a function in the shared library, 92.
  • a pointer to a modified function descriptor is retrieved from the table of contents of the shared library corresponding to the function thus-called, 94.
  • a pointer is thereafter retrieved from the modified function descriptor to a wrapper corresponding to the function in the modified function descriptor, 96.
  • wrapper code is thence executed as a result of obtaining this pointer, e.g. in response to the modified function descriptor pointer, whereupon a lock is obtained on the function which is desired to be executed, 98.
  • the particular function thereafter executes whereby, as a result of the lock, data corruption is avoided by calls from any thread occurring after the one which invoked the function's execution, shown at reference numeral 100.
  • wrapper code executes in response to the return to thereby unlock the global lock which locked the function, 102.
  • return of control is provided to the application program to permit execution of a subsequent call caused by a next thread, 104, whereupon the previously described sequence of events has thus been terminated, 106.

Abstract

Libraries for use in a multithreaded computer environment which must be thread-safe and cannot be recoded are identified. Such libraries, after identification, are repackaged. Export routines for such libraries will thereby acquire a front end which effects several steps. First a write-exclusive lock for a particular called function of one of the libraries is generically acquired. A call is then made to the underlying function whose name has been remapped. Upon return from the real routine, the write-exclusive lock is unlocked and a return to the user is executed. The system and method ensure correct functioning and integrity of the identified library functions accessible by multiple threads, as well as providing for creation of multithread-safe shared libraries without necessitating extensive library source modifications.

Description

TECHNICAL FIELD
This invention relates to systems and methods for managing shared resources in a computer system, and, more particularly, to shared resource management techniques in multithread environments.
BACKGROUND OF THE INVENTION
In order to better understand the background of the subject invention, explanation of some of the terminology utilized hereinafter will first be provided. A term well known in the art as a symmetric multiprocessor (SMP) refers to an aspect of hardware in a computing system and, more particularly, relates to the physical layout and design of the processor planar itself. Such multiple processor units have, as one characteristic, the sharing of global memory as well as equal access to I/O in such a typical SMP system.
Yet another such term which will be hereinafter used and commonly associated with modern complex computing systems is a "thread". The term thread in a general sense refers merely to a simple execution path through application software and the kernel of an operating system executing with the computer. As is also well understood in the art, it is commonplace for multiple such threads to be allowed per a single process image.
Yet another concept which will be utilized hereinafter in describing the invention is one of "locks" or "mutexes". It is typical in modern computing systems to have critical sections of code or shared data structures such as in shared libraries whose integrity is extremely important to the correct operation of the system. Such locks/mutexes are devices employed in software (and hardware) to "serialize" access to these critical sections of code and/or shared data structures.
Two types of locks are typically encountered in the art, namely blocking locks and simple or "spin" locks. Blocking locks are of the form which cause a thread requesting the lock to cease being executable, e.g. to go to "sleep" as the term is employed in the art, if the lock is currently held by another thread. Spin locks, in contrast, do not put waiting threads to "sleep", but rather, the waiting threads execute a spin loop, and thus repeatedly continue to request the lock until it is freed by the current thread "owner". Blocking locks are typically used for large critical sections of code or if the operating system kernel must differentiate between threads requiring data structure read-only capability and threads requiring the capability to modify the data structure(s). This latter read-write type lock may be found implemented, for example, in the current OSF/1 operating system release of the Open Software Foundation (OSF).
One other term utilized hereinafter is the concept of code being multithread-safe. Such code is considered to be thread/MP-safe if multiple execution threads contending for the same resource or routine are serialized such that data integrity is ensured for all such threads. One way of effecting this is by means of the aforementioned locks.
In modern uniprocessor, single process model systems employing shared libraries, routines in such shared libraries do not require any form of hereinbefore noted serialization with respect to other routines in the library or multiple callers of the same routine. There is thus no problem with respect to shared or global data structures requiring use of locks or mutexes to prevent conception.
Moreover, even as between processes in multiprocessor systems, data corruption problems are typically avoided where private/local copies are data are maintained by the respective processes.
As a specific example of the foregoing, in version 3.2 of the AIX(tm) operating system of the IBM Corporation, shared libraries shipped for execution on compatible machines have to only run in a single process model on a uniprocessor system. Accordingly, there is no need for utilizing locks or mutexes to serialize access to shared or global data structures. However, in contrast, with respect to subsequent releases of the aforesaid operating system such as that employing Distributed Computing Environment (DCE) functionality, the process model has been changed from a single process to multiple threads per process. There are several benefits to this extension, not the least of which is concurrent programming.
However, such improvements in operating system technology have given rise to the problem addressed by the instant invention. With the advent of multithreaded systems, the requirement has arisen that the libraries associated therewith must be modified to either be thread-efficient or at the very least thread-safe. The added complexity of multiprocessor forms of such systems only exacerbates the problem of maintaining system integrity.
Applications which have been bound unshared with libraries do not require changes to the libraries inasmuch as they will maintain the single process model (e.g. a single thread, single process model). However, in other cases wherein the process model changes from a single thread single process to multiple threads per process, methods and systems were required to be devised which could render such libraries effectively thread-efficient or at least thread-safe. The practical constraint of programming resources simply renders it impractical to thread-safe all library routines in a modern multithreaded system. Thus, systems and methods were needed to enable the creation of multithread-safe shared libraries without the necessity for source code modifications of the library itself.
By way of further background, a typical multiprocessor environment with shared resource management may be seen described in U.S. Pat. No. 5,109,511 entitled "Shared Resource Managing Method and System". However, in this system no lock operations are provided for. In yet another reference, U.S. Pat. No. 4,847,754, there is disclosed another multiprocessor environment providing for serialization of access to shared resources among concurrent processes which does call for a lock mechanism. However the system provides for a two-step serialization process requiring an access initiation operation followed by an access completion operation.
Yet another shared resource system for concurrent processes in a multi-process environment may be seen in "Memory Protection Software Facility for OS/2 Shared Data Application", IBM Technical Disclosure Bulletin, Vol. 34, No. 4A, 9/91. This reference describes a technique for isolating memory areas in, for example, Intel 386 architected systems wherein a facility is provided for dynamic link libraries (DLLs) to protect their critical shared global data regions. However, no protection is provided for the DLLs from each other, the technique disclosed requires altered process address spaces, and, moreover, has undesirable hardware dependencies.
Several approaches to addressing the specific problem met by the subject invention are available, all of which include concomitant and very undesirable drawbacks.
As but one example, in seeking to effect multithreaded and multiprocessor shared libraries which are thread-safe, one approach is to simply rewrite all libraries to add locks. As a practical matter, a modern complex computing system may involve numerous such libraries. In the case of the aforesaid AIX system, there are in excess of 70 libraries including, for example, a socket library in excess of one megabyte. Obviously, to rewrite all such libraries would entail a resource commitment far in excess of that which is practical to maintain a commercially viable system.
Yet another approach is simply to do nothing with respect to the existing libraries in terms of rewriting code, but rather simply to document libraries which are not thread-safe. This approach obviously has serious drawbacks itself, not the least of which is maintaining the accuracy of such documentation and the impact on system integrity from errors in documentation.
From the foregoing it may be readily understood that lack of a system and method for creating thread-safe shared libraries has created serious problems with respect to modern complex computing environments, and thus a solution was sorely needed in the industry.
It is accordingly an object of the invention to provide systems and methods for creating thread-safe shared libraries; it is yet a further object of the invention to provide for such shared libraries and their usage without the necessity for source-code modifications of the library.
These and other objects have been fully met by the subject invention, a description of which hereinafter follows which may be more easily understood with reference to the following drawings wherein:
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a schematic diagram of the structural components of a representative multithreaded computer system which may advantageously employ the computer system;
FIG. 2 is a more detailed illustration of a portion of the system of FIG. 1, depicting aspects of the shared resource components of FIG. 1;
FIG. 3 is a flow diagram illustrating the method for creating thread-safe libraries in accordance with the invention.
FIG. 4 is a flow diagram illustrating the thread-safe usage of shared libraries in accordance with the invention.
SUMMARY OF THE INVENTION
Libraries for use in a multithreaded computer environment which must be thread-safe and cannot be recoded are identified. Such libraries, after identification, are repackaged. Export routines for such libraries will thereby acquire a front end which effects several steps. First a write-exclusive lock for a particular called function of one of the libraries is generically acquired. A call is then made to the underlying function whose name has been remapped. Upon return from the real routine, the write-exclusive lock is unlocked and a return to the user is executed. The system and method ensure correct functioning and integrity of the identified library functions accessible by multiple threads, as well as providing for creation of multithread-safe shared libraries without necessitating extensive library source modifications.
In a preferred embodiment for generating thread-safe functions, shared library functions not to be modified are identified and an export list of external functions extracted. Function descriptors corresponding to each function are saved, and a wrapper generated for each function with a global lock and further having a corresponding one of the saved function descriptors. Modified function descriptors are created for each function descriptor, each having an address of a corresponding wrapper entry point. The table of contents to the shared library is modified so that a pointer is returned in response to a function call to the modified function descriptor rather than to the original function descriptor. The corresponding wrapper to which the modified function descriptor pointer points includes, in the copy of the function descriptor contained therein, a pointer to the same function as the original function descriptor. This pointer invokes a lock on the function, whereupon the function code executes and issues a return, whereupon the lock is released. The pointer in the copy of the function descriptor in the wrapper is identical to that of the original function descriptor.
Also in a preferred embodiment of the invention for invoking shared library functions in a thread-safe manner, a call is issued to execute a function of a shared library. A pointer is retrieved from a table of contents of the shared library in response to the function call pointing to a modified function descriptor. A pointer is retrieved from the modified function descriptor, in turn pointing to a wrapper corresponding to the function. The wrapper contains a substantial copy of the original function descriptor, and, in particular, includes the same pointer as the original function descriptor to the executable function code. Upon invoking the wrapper code, this pointer causes execution of a lock on the function and subsequent execution of the function itself. Upon return of the function, the wrapper code, in response, releases the lock and returns control for invocation of a next thread and corresponding function.
Wrappers are provided for each externalized function of the shared library whereby, in combination, they effect a wrapper around the executable shared library code. In this manner, due to the lock invoked when wrapper code corresponding to a given function is executed, the function is thereby made thread-safe. Data associated with the function thus may not be corrupted by a call by a subsequent thread, and the memory associated with the data is not released until the lock is released.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
FIG. 1 depicts a multithread computer system with multiple processes sharing a shared library in accordance with the prior art. Accordingly, multiple processes A and B as shown are reference numerals 10, 12, respectively, and a shared library 14. It will be recalled from the foregoing that in single threaded process models of the prior art, corrupting library data was not a problem since a process would have its own copy of data, such as the copy of data 24 shown at reference numeral 20 or 22. A given process thus did not have access to the data 24 of the shared library 14 and only one thread, such as thread 1 shown at reference numeral 16 of process A, was permitted to access the copy 20 of the data at a given time.
In contrast, still referring to FIG. 1, in a multithread application such as that shown, if multiple such threads (such as threads 1 and 2 shown at reference numeral 16 and 17) are permitted to access the data 24 of the shared library 14 at the same time, corruption of the data will result. In systems such as those shown in FIG. 1, the multiple threads (such as threads 16 and 17 of one process such as process A, reference numeral 10), have access to their own copy 20 of the shared library data 24 but cannot access the shared library data 24 or the other process private copy 22 of the data corresponding to process B at reference numeral 12.
The conventional way to access data 24 in a shared library 14 is through routines or code 23 provided by the shared library 14. This code 23 will change shared library data 24 and generate pointers and the like thereby managing the data copies 20 and 24 with local and global variables, tables, hashing queues, and the like.
The multiple processes such as process A and B usually do not access the data 24, but rather go through the shared library routines of code 23, which duplicate the data 24 of the shared library and pass back information to respective processes based upon what the shared library code 23 did during such management. As noted, the data from the shared library must thus be unique per process, e.g. a pristine copy of the data 24 must be provided as in copies 20 and 22 to each respective process 10, 12, whereby the multiple processes and threads will not corrupt the data 24 of the shared library 14 itself. It will be noted, in passing, that in some cases, the routine or function call generated from the shared library code 23 will indicate that it is using a piece of data 24 for some working storage space. In these instances it will pass back an exact address of the data 24 in the shared library 14 to the calling thread from the particular process.
To illustrate the specific problem of data corruption which can arise from multithread processes such as those shown in FIG. 1, it will first be noted that it is typical for function calls from processes to a shared library 14 to utilize global data. An example of this is the well known printf function which will have a global data area wherein modifications are performed on a data stream which is desired to be printed out. It is important to note that conventionally only one such global data area for printf is provided per process. It will be readily apparent then, that if multiple threads 16, 17, for example, of a process A, reference numeral 10, call the same function, (e.g. printf) at the same time, each thread will be attempting to use the identical global data area, thereby corrupting it with the inputs of the differing threads resulting in invalid outputs.
Numerous solutions to the aforementioned problems have been attempted. One approach is to rewrite the entirety of the functions of a library such as the aforementioned printf as well as its corresponding underlying routines to be thread-safe. This entails allocating unique portions of data storage such as at reference numeral 20, so that when a thread 17 calls a given function, such as printf or malloc, the thread of the function will use a different section of memory than that employed by a prior thread calling the same function.
Yet another approach is to provide a lock on the global data area of the particular function such as printf or malloc. In summary then, there are differing ways to make library routines thread-safe such as providing locks, having the functions pass the data area, utilizing a unique data area, having the function lock and unlock a common data area and provide returns giving the status of the lock. However, all of these approaches require extra work and coding such as recoding the actual library functions as previously mentioned in a manner to render them thread-safe.
Thus, not only were such prior art attempts to solve the problem impractical in terms of the resources required for recoding, but further undesirable results occur from these approaches. For example, it is highly undesirable for end users to assume the responsibility of modifying library source inasmuch as such code changes can easily result in source compatibility problems. Requiring changes of code in the shared library 14 or applications (e.g. those invoking multiple processes such as process A and B) to fix the problem was highly undesirable, as it is much more preferable to facilitate the continued use of existing libraries and avoiding the necessity of code changes.
Turning to FIG. 2 now, a description will be provided of the system and method of the invention for solving the aforementioned problems. The solution essentially entails placing a wrapper around the code 23 of the shared library 14 (rather than the data 24) in a manner to be detailed.
Library functions in a given shared library have corresponding routines and function names which the given shared library "exports", i.e. which are available to an end user or application to call. A representative such export list for shared library 14 is shown at reference numeral 26 of FIG. 1. It is conventional that when applications are built, the application is able to locate a symbol in corresponding function code of a given shared library because of the export list 26 providing the information of what the external function calls are which are available outside the shared library for use by an application. An example of such an entry in the export list would be the aforementioned printf or malloc external interface function names. More particularly, it is conventional to have a library file such as lib.exp as part of the shared library which is simply an ASCII file or string of all symbols exported from the shared library (such as malloc, free, printf . . . ).
The concept of the invention entails, in part, employing this export list of all exported function names from a given library and placing "wrappers" around each such function. A wrapper is simply code extending around the instantiation of the call of the given corresponding function. If, for example, a thread calls a malloc function, in providing a "wrapper" for the particular function, this simply means placing another malloc (e.g. the wrapper) on top of the pre-existing function call such as malloc and renaming the underlying one. Thus, when a user or thread calls a function such as malloc, the wrappered underlying version of malloc is called from the wrapper on top of the renamed underlying version. The underlying version will then obtain a lock, which in turn recalls the underlying malloc function to do the real memory allocation function of the malloc function, The actual real malloc function then returns back to the wrapper which completes the wrappered functions necessary to complete the desired action, such as unlocking the lock, freeing data, and the like. Thus, a wrapper will be seen to be an individual piece of code placed around a corresponding individual function call or routine which is exported from the shared library.
By doing so, the invention thereby protects all the function calls within the shared library from each other (e.g. separate calls to different functions from different multiple threads attempting to use the same data area) and further protects the calls from themselves (e.g. multiple calls from multiple threads to the same function such as printf, attempting to use again, the same data area for both such calls).
The aforementioned locks associated with the individual wrappers for each function will in actuality be the same global lock which each function will sequentially obtain at a given time upon execution of its corresponding wrapper code. For example, since a system does not know what given library routines are using for their global data areas and what memory they are accessing, this global lock will prevent malloc from potentially overriding or otherwise corrupting the data area currently being employed by printf inasmuch as printf will acquire the lock, thus locking out malloc from corrupting that area until printf frees the lock. Thus it will be seen that all wrappers will obtain the same lock providing for relatively coarse serialization but nevertheless effecting the objects of the invention in preventing data corruption.
From the foregoing, it is apparent that when wrapper code for a given function is invoked, the same lock will be locked no matter what the routine is that is being called through the particular wrapper function. In response, after effecting the lock, the real code of the routine will then be called and executed, whereupon after a return is received from the routine, the wrapper's lock is unlocked, thereby freeing the data area for use by a call from a subsequent thread.
When a wrapper around each of the externalized functions of the given shared library has thus been provided, the library may thus be thought of as being thread-safe by means of this collection of wrappers. It will be recalled that there are instances wherein the actual library functions themselves simply cannot be recoded individually to provide a similar thread-safe characteristic. For example, an end user may have received an application shipped with a prior version of an operating system who now wants to run the application on a new version of the operating system but does not have access to the source code, does not want to repurchase it or have the vendor re-port it. In other words, in such instances the end user, even if he otherwise had the resources to recode the functions, could not do so without access to the source to recode the shared libraries or application. The user would thus lave a problem in assuring thread-safe operation unless the vendor could be persuaded to either ship a thread-safe version of the shared library or to otherwise permit the end user to effect this through recoding (which can be prohibitively expensive as well as giving rise to source incompatibilities as previously noted).
In accordance with the invention, by provision for the aforesaid wrappers, there is, in a limited sense, a necessity to nevertheless modify the shared library code. However an important distinction is to note that in accordance with the invention, the internal functions (binary or source code) need not themselves be recoded or altered. Thus the reshaping or modification of the shared library may be thought of as actually essentially occurring on top of or on the outer portion of the shared library, giving rise to the notion of a collection of "wrappers" around the code 23 of FIG. 1. In essence, then, it will be seen that the "old" binary of the shared library prior to rendering it thread-safe in accordance with the invention may be saved off. This is because the changes entailed by the invention are beyond the binary image of the library and are effected by adding wrappers around the individual routines in the rebuilding of the library. The invention only modifies the entry points to the shared library to now point to the wrappers, without necessitating modifying the internal function calls and function code as was the case in the prior art.
The initial build of the shared library will include creation of the aforementioned export list 26. In accordance with the invention, then, this export list is then extracted from the shared library, yielding a list of all the exported symbols, e.g. externalizing function call names in the shared library. They are then essentially renamed whereby an identical function either before or after modifications in accordance with invention will nevertheless be executed by the same call. The identical function name will essentially invoke a pointer in a table of contents not to the old function descriptor existing prior to the modifications of the invention, but rather to a new function descriptor which, in turn, contains a pointer to the wrapper code corresponding to the function thus called.
Turning now to FIG. 2, an explanation will be provided of the functional blocks depicted therein implementing the invention.
First it will be recalled that the export list 26 of FIG. 1 has been previously generated as a part of the prior shared library and is extracted therefrom. It is conventionally simply in ASCII format inside the shared library, and the extraction comprises locating it in the memory of the shared library, e.g. where all the names of exported functions corresponding to the shared library exist (e.g. those externalized by the library and accessible by the user).
Once this export list of externalized function calls has been obtained, they are renamed through the process of adding and building new wrapper modules with corresponding names from the export list. These modules are thence placed back in the existing library in a manner to be described.
With continued reference to FIG. 2, each function such as "foo" in a given library has an associated function call 28 with a corresponding associated entry point in a table of contents 30. This is essentially a pointer or address of an entry point, e.g. in the example under consideration a descriptor address 34 of the foo function which points to a function descriptor 32. The function descriptor, in conventional operation, contains the address of the entry point, 42, of the corresponding function or routine, e.g. the foo code 50. In this manner, accessing the function descriptor 32 by means of the foo call 28 will cause a pointer 48 to be invoked to the foo code 50 whereupon the desired library routine or foo code will execute. The function descriptor 32 will also, conventionally, contain the address and memory, 44, of the table of contents 30, as well as data 46. Typically, also, one such table of contents 30 exists per shared library 14. In essence, in order to rename the function as previously described, this simply entails changing the symbol and storing off the function pointer. More particularly, a new function descriptor 38 is created, and the descriptor address 34 of the table of contents 30 is modified to point to this new function descriptor as shown by the arrow 40. Thus, in response to a function call 28, the table of contents 30, and, more particularly, the particular function's descriptor address 34, will now cause a pointing to the new or modified function descriptor 38 shown by arrow 40, rather than to the prior function descriptor 32 shown by the dotted arrow 36. In other words, the entry point of this new or modified function descriptor 38 is actually what is replaced into the address 34 of the table of contents in place of that or the prior function descriptor 32.
Continuing with FIG. 2, this new function descriptor 38, in comparison with the function descriptor 32, will be seen to be essentially a copy of the prior function descriptor 32, containing the same address of table of contents 54, and data 56. However, the significant difference between the two descriptors is that in the case of the address of the entry point, whereas the address or re-entry point 42 of the function descriptor 32 pointed to the actual routine code 50, the address of the modified function descriptor 38 shown at reference numeral 52 is now modified to be the address of the wrapper's entry point for the wrapper code 62. Thus, in response to the function call 28, the function descriptor 38 is invoked, whereupon the address of the wrapper's entry point 52 is, in turn, utilized to effect the pointer 58 to wrapper code 62.
Continuing with FIG. 2, the wrapper code 62 for each function 28 will include code necessary to invoke the locking and unlocking of the previously described global lock, shown in the wrapper code as lock 68 and unlock 72. When the wrapper code 62 is invoked by use of the pointer 58, the lock is locked by means of the execution of the lock code 68, whereupon the function descriptor 70 of the wrapper code 62 is employed. It is important to note that this function descriptor 70 is essentially identical to that of the prior function descriptor 32. More particularly and more importantly, however, the address of the entry point 42 in the function descriptor 32 is identical to that of the function descriptor 70. This will cause a pointing (schematically shown by pointer 64) to the actual executable code of the library routine such as foo code 50 in the identical manner that the address of the entry point 42 of the function descriptor 32, by means of the pointer 48, also caused execution of such library routine code 50 prior to provision of the function descriptor 38 and wrapper code 62.
When the foo code 50 completes executing, a return (shown as reference numeral 66) to the wrapper code 62 thereafter causes invocation of unlock code 72 to free the lock on the address space previously being utilized by execution of the particular library function. After this unlocking, this effects a return 60 to, ultimately, permit a function call by a next thread wherein the previous process is repeated. When the next call from a next thread sequentially is presented, in like manner, it will result in a pointer from the table of contents 30 to its corresponding function descriptor (which will differ for each of the functions in the library), in which case the previously described functions will again be replicated to cause execution of the actual library routine corresponding to this new function call from the next thread.
In summary, then, it is a significant feature of the invention to provide for new creation of these function descriptors 38, each corresponding to a function descriptor 32. Each prior function descriptor 32 is saved off for use in the wrapper code module 62 (as shown by function descriptor 70), wherein each wrapper code module corresponds to one of the function descriptors 32, a corresponding one of the function descriptors 38, and a corresponding function in the shared library. The table of contents 30 is modified and, more particularly, the function's entry in the table of contents is modified to now point to the new function descriptor 38.
When the user binds the new library, the table of contents is modified to call ultimately these wrapper routines (represented by wrapper code 62) and not the "old" or prior function descriptor 32 and routine code. If the latter were to happen, it will be readily apparent that the library function 50 would not be thread-safe inasmuch as no lock would have been provided. A subsequent function call from a next thread could then destroy data integrity. However, in accordance with the invention, the wrapper code 62 causes obtaining of the lock and calling of the actual underlying function previously in the library which is thus protected.
Rebuilding of the prior shared library essentially entails, in addition to creating the new function descriptors 38 and wrapper code 62, modifying the table of contents 30 to point to these new functions descriptors 38. Also, the "renaming" of the old modules (such as foo code 50) really simply entails changing how they are accessed. Now, they are accessed actually by invoking the wrapper code 62. It will be appreciated from the foregoing that path length has thus been increased arising from the addition of the wrapper code 62, the lock and unlock functions, and the extra function call (e.g. calling of the renamed function and the calling of the actual function itself). However, the effecting of a thread-safe shared library has thus nevertheless been implemented affording the other benefits not present in prior art approaches.
Referring now to FIG. 3, a flow diagram is shown illustrating the steps of creating the thread-safe library. The process is entered at 74, whereupon shared library functions which are not to be re-coded are identified, 76. From the shared library or libraries, an export list is extracted listing all the symbols of the corresponding functions in the given library or libraries which are not to be recoded. Once this export list has been extracted, 78, the prior function descriptors corresponding to each function are saved off, 80. Next a wrapper is generated for each such function which will activate and deactivate a global lock, 82. A modified function descriptor for each prior function descriptor is constructed with an address or pointer to a corresponding wrapper entry point for the wrapper generated at reference numeral 82. This step of creating the modified function descriptors is shown at reference numeral 84. The table of content(s) is then modified to the shared library or libraries so that a pointer is now returned, in response to a given function call, to a corresponding modified function descriptor rather than the original function descriptor.
Referring now to FIG. 4, a simplified flow diagram is shown of the sequence of operation in accordance with the invention whereby a function from a multithread process is invoked (whereby the corresponding library routine is executed in a thread-safe manner in accordance with the invention). The sequence is entered at 90 whereupon a function call is issued to execute a function in the shared library, 92. In response to this call, a pointer to a modified function descriptor is retrieved from the table of contents of the shared library corresponding to the function thus-called, 94. A pointer is thereafter retrieved from the modified function descriptor to a wrapper corresponding to the function in the modified function descriptor, 96.
The wrapper code is thence executed as a result of obtaining this pointer, e.g. in response to the modified function descriptor pointer, whereupon a lock is obtained on the function which is desired to be executed, 98. The particular function thereafter executes whereby, as a result of the lock, data corruption is avoided by calls from any thread occurring after the one which invoked the function's execution, shown at reference numeral 100. Upon return of the function, wrapper code executes in response to the return to thereby unlock the global lock which locked the function, 102. After the lock has been released, return of control is provided to the application program to permit execution of a subsequent call caused by a next thread, 104, whereupon the previously described sequence of events has thus been terminated, 106.
While the invention has been shown and described with reference to particular embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and detail may be made therein without departing from the spirit and scope of the invention.

Claims (6)

What is claimed is:
1. A method for use in a multithread computer system employing a pre-existing shared library having a pre-existing function descriptor, a pointer to said function descriptor and a corresponding at least one function which is not multithread-safe when used in said system having a corresponding underlying call associated therewith exported from said library to render said shared library multithread-safe when used in said system, comprising:
creating a wrapper for said function comprised of program code extending around instantiation of said underlying call said wrapper being responsive to a call corresponding to said underlying call, said creating including the steps of
storing said pre-existing function descriptor therewithin, and creating a lock to said function; and
rebinding said pre-existing shared library with said wrapper including the steps of
creating a modified function descriptor including
creating a pointer to said wrapper and
creating a copy of said function descriptor with said pointer to said wrapper
in said modified function descriptor being substituted for said pointer to said function in said function descriptor during said rebinding; and
substituting a pointer to said modified pointer descriptor for said pointer to said function descriptor.
2. The method of claim 1 wherein calling said function before and after said rebinding invokes said pointer to said function descriptor and said pointer to said modified function descriptor, respectively.
3. The method of claim 2 wherein said function descriptor includes a pointer to a routine corresponding to said function.
4. A method for modifying a multithread shared library computer system in which an underlying function call exported from said shared library invokes a pointer to a function descriptor which, in turn, invokes a pointer to a corresponding routine of said shared library thereby causing execution of said routine, whereby multithread safe use of said shared library is facilitated said method comprising:
providing a wrapper including a lock being comprised of program code extending around instantiation of said underlying function call, said wrapper being responsive to a call corresponding to said underlying call and including a lock for said routine, said wrapper further including said function descriptor;
providing a substitute function descriptor with a pointer to said wrapper;
changing said pointer to said function descriptor into a pointer to said substitute function descriptor;
invoking said pointer to said substitute function descriptor;
invoking with said pointer to said substitute function descriptor said pointer to said wrapper; and
invoking with said pointer to said wrapper execution of said wrapper including
executing said routine from said function call sequentially through said substitute function descriptor and then through said wrapper including said function descriptor;
executing a lock on said routine;
invoking said pointer of said function descriptor in said wrapper to said routine thereby causing its execution; and
unlocking said lock on said routine in response to a return to said wrapper from said routine.
5. The method of claim 4 wherein said lock and said unlocking precludes and permits, respectively, execution of said routine from a subsequent said function call from another of said multiple threads while said routine is executing.
6. A system for use in a multithread computer system employing a pre-existing shared library having a pre-existing function descriptor, a pointer to said function descriptor, and a corresponding at least one function which is not multithread-safe when used in said system having a corresponding underlying call associated therewith exported from said library to render said shared library multithread-safe when used in said system, comprising:
means for creating a wrapper for said function comprised of program code extending around instantiation of said underlying call, said wrapper being responsive to a call corresponding to said underlying call, said means for creating a wrapper further including
means for storing said pre-existing function descriptor therewithin; and
means for creating a lock to said function; and
means for rebinding said pre-existing shared library with said wrapper said means for rebinding including
means for creating a modified function descriptor including
means for creating a pointer to said wrapper and
means for creating a copy of said function descriptor with said pointer to said wrapper in said modified function descriptor, being substituted for said pointer to said function in said function descriptor during said rebinding; and
means for substituting a pointer to said modified pointer descriptor for said pointer to said function descriptor.
US08/143,586 1993-11-01 1993-11-01 System and method for creating thread-safe shared libraries Expired - Fee Related US5481706A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US08/143,586 US5481706A (en) 1993-11-01 1993-11-01 System and method for creating thread-safe shared libraries

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US08/143,586 US5481706A (en) 1993-11-01 1993-11-01 System and method for creating thread-safe shared libraries

Publications (1)

Publication Number Publication Date
US5481706A true US5481706A (en) 1996-01-02

Family

ID=22504713

Family Applications (1)

Application Number Title Priority Date Filing Date
US08/143,586 Expired - Fee Related US5481706A (en) 1993-11-01 1993-11-01 System and method for creating thread-safe shared libraries

Country Status (1)

Country Link
US (1) US5481706A (en)

Cited By (78)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5630136A (en) * 1995-06-09 1997-05-13 Sun Microsystems, Inc. Method and apparatus for serializing access to multithreading unsafe resources
US5822588A (en) * 1995-06-09 1998-10-13 Sun Microsystem, Inc. System and method for checking the use of synchronization locks in a multi-threaded target program
US5832265A (en) * 1993-03-22 1998-11-03 Siemens Nixdorf Informationssysteme Aktiengesellschaft Reentrant libraries
US5901317A (en) * 1996-03-25 1999-05-04 Sun Microsystems, Inc. Method and system for register allocation using multiple interference graphs
US5901316A (en) * 1996-07-01 1999-05-04 Sun Microsystems, Inc. Float register spill cache method, system, and computer program product
US5938743A (en) * 1997-03-17 1999-08-17 Xerox Corporation Method of using the UNIX physio to allow data to be transferred on a plurality of channels concurrently
US5958028A (en) * 1997-07-22 1999-09-28 National Instruments Corporation GPIB system and method which allows multiple thread access to global variables
US5987259A (en) * 1997-06-30 1999-11-16 Sun Microsystems, Inc. Functional unit switching for the allocation of registers
US6006278A (en) * 1997-07-18 1999-12-21 Electronic Data Systems Corporation Method and system for importing remote functions to a network computer
US6009272A (en) * 1997-06-30 1999-12-28 Sun Microsystems, Inc. Register allocation via selective spilling
US6105050A (en) * 1998-08-25 2000-08-15 International Business Machines Corporation System for resource lock/unlock capability in multithreaded computer environment
US6105049A (en) * 1998-08-25 2000-08-15 International Business Machines Corporation Resource lock/unlock capability in multithreaded computer environment
US6112222A (en) * 1998-08-25 2000-08-29 International Business Machines Corporation Method for resource lock/unlock capability in multithreaded computer environment
US6131188A (en) * 1995-12-22 2000-10-10 Sun Microsystems, Inc. System and method for reducing the occurrence of window use overflow
US6139200A (en) * 1997-06-30 2000-10-31 Sun Microsystems, Inc. Register resource allocation feedback
US6148325A (en) * 1994-06-30 2000-11-14 Microsoft Corporation Method and system for protecting shared code and data in a multitasking operating system
US6173309B1 (en) * 1997-02-20 2001-01-09 Hewlett-Packard Company Null thread library and thread abstraction interface
US6189023B1 (en) * 1997-09-30 2001-02-13 Tandem Computers Incorporated Simulating shared code thread modules with shared code fibers
US6249803B1 (en) 1997-12-18 2001-06-19 Sun Microsystems, Inc. Method and apparatus for executing code during method invocation
US6275871B1 (en) * 1996-07-03 2001-08-14 Siemens Aktiengesellschaft Asynchronous transport optimizing observer-pattern-like system supporting several modes for an interface definition language-less communication subsystem
US6295611B1 (en) 1998-12-14 2001-09-25 Sun Microsystems, Inc.. Method and system for software recovery
US20020055965A1 (en) * 1997-05-14 2002-05-09 Microsoft Corporation Method and system for accessing objects of different thread types
US20020059358A1 (en) * 1997-07-17 2002-05-16 Microsoft Corporation Method and system for accessing objects of different thread types
US6405264B1 (en) 1997-12-18 2002-06-11 Sun Microsystems, Inc. Marshaling and unmarshaling framework for supporting filters in a distributed object system
US6490609B1 (en) * 1998-01-09 2002-12-03 Sun Microsystems, Inc. Method, apparatus and computer program product for invoking a thread-unaware routine that uses an operation-dependent temporary data structure
US6490617B1 (en) * 1998-06-09 2002-12-03 Compaq Information Technologies Group, L.P. Active self discovery of devices that participate in a network
US6510460B1 (en) * 1997-12-18 2003-01-21 Sun Microsystems, Inc. Method and apparatus for enforcing locking invariants in multi-threaded systems
US20030022663A1 (en) * 2001-07-26 2003-01-30 Gowri Rajaram System and method for field downloading a wireless communications device software code section
US20030022665A1 (en) * 2001-07-26 2003-01-30 Gowri Rajaram System and method for organizing field upgradable wireless communication device software
US6516354B2 (en) 1997-12-18 2003-02-04 Sun Microsystems, Inc. Method and apparatus for efficient representation of variable length identifiers in a distributed object system
US20030033525A1 (en) * 2001-08-10 2003-02-13 Gowri Rajaram System and method for improved security in handset reprovisioning and reprogramming
US20030033599A1 (en) * 2001-07-26 2003-02-13 Gowri Rajaram System and method for executing wireless communications device dynamic instruction sets
US20030064717A1 (en) * 2001-07-26 2003-04-03 Gowri Rajaram System and method for the management of wireless communications device system software downloads in the field
US20030069007A1 (en) * 2001-07-26 2003-04-10 Gowri Rajaram System and method for updating persistent data in a wireless communications device
US20030110480A1 (en) * 2001-08-10 2003-06-12 Gowri Rajaram System and method for peer-to-peer handset communication
US20030110479A1 (en) * 2001-08-10 2003-06-12 Gowri Rajaram System and method for bi-directional communication and execution of dynamic instruction sets
US6622155B1 (en) 1998-11-24 2003-09-16 Sun Microsystems, Inc. Distributed monitor concurrency control
US20030182572A1 (en) * 2001-12-06 2003-09-25 Cowan Stanley Crispin Pointguard: method and system for protecting programs against pointer corruption attacks
US20030233393A1 (en) * 2002-06-14 2003-12-18 Xiao-Feng Li Thread optimization for lock and unlock operations in a multi-thread environment
US20030233430A1 (en) * 2002-06-13 2003-12-18 International Business Machines Corporation Method of modifying a logical library configuration from a remote management application
US6684394B1 (en) * 1999-09-03 2004-01-27 Stmicroelectronics Limited Relocation format for linking with relocation instructions containing operations for combining section data
US20040111720A1 (en) * 2001-02-01 2004-06-10 Vertes Marc Philippe Method and system for managing shared-library executables
US6760909B1 (en) * 1996-04-29 2004-07-06 Microsoft Corporation Virtual memory system and methods
US6782537B1 (en) 1999-09-23 2004-08-24 International Business Machines Corporation Establishing a communicator across multiple processes in a multithreaded computing environment
US20040214561A1 (en) * 2001-07-26 2004-10-28 Kyocera Wireless Corp. Dynamic interface software for wireless communication devices
US20040214560A1 (en) * 2001-07-26 2004-10-28 Kyocera Wireless Corp. Modular software components for wireless communication devices
US20040214559A1 (en) * 2001-07-26 2004-10-28 Kyocera Wireless Corp. System and method for interchangeable modular hardware components for wireless communication devices
US6851114B1 (en) * 2000-11-06 2005-02-01 Sun Microsystems, Inc. Method for improving the performance of safe language multitasking
US20050039187A1 (en) * 2003-08-12 2005-02-17 Avakian Arra E. Instrumenting java code by modifying bytecodes
US20050066303A1 (en) * 2003-09-22 2005-03-24 Trigence Corp. Computing system having user mode critical system elements as shared libraries
US20050064847A1 (en) * 2001-07-26 2005-03-24 Bilhan Kirbas System and method for over the air area code update
US20050172293A1 (en) * 2004-01-27 2005-08-04 Network Appliance, Inc. Method and apparatus for allocating resources in a shared resource processor
US20050223199A1 (en) * 2004-03-31 2005-10-06 Grochowski Edward T Method and system to provide user-level multithreading
US6996808B1 (en) * 2000-02-12 2006-02-07 Microsoft Corporation Function injector
US20060200809A1 (en) * 2005-03-03 2006-09-07 Nikola Grcevski Transforming code to expose glacial constants to a compiler
US7159214B2 (en) 2001-07-26 2007-01-02 Kyocera Wireless Corp. System and method for compacting field upgradeable wireless communication device software code sections
US7178137B1 (en) 2001-04-05 2007-02-13 Network Appliance, Inc. Automatic verification of scheduling domain consistency
US7185316B1 (en) * 1994-11-16 2007-02-27 Morris Robert M Visually oriented computer implemented application development system utilizing standardized objects and multiple views
US20070094529A1 (en) * 2005-10-20 2007-04-26 Lango Jason A Method and apparatus for increasing throughput in a storage server
US20070240135A1 (en) * 2006-03-09 2007-10-11 Stoodley Kevin A Programmatic compiler optimization of glacial constants
US7293213B1 (en) * 2004-09-16 2007-11-06 At&T Corp. Method for detecting software errors and vulnerabilities
US20070291124A1 (en) * 2006-06-20 2007-12-20 David Staudacher Event management for camera systems
US20080209432A1 (en) * 2006-06-15 2008-08-28 Guruduth Somasekhara Banavar Computer implemented method and system for sharing resources among hierarchical containers of resources
US7487152B1 (en) 2000-05-31 2009-02-03 International Business Machines Corporation Method for efficiently locking resources of a global data repository
US20090178060A1 (en) * 2008-01-07 2009-07-09 Dell Products L.P. Method, Apparatus and System for Automatic Loading of a Network Stack
US20090198968A1 (en) * 2008-02-04 2009-08-06 Colin Penfold Method, Apparatus and Software for Processing Software for Use in a Multithreaded Processing Environment
US20090300766A1 (en) * 2008-06-02 2009-12-03 Microsoft Corporation Blocking and bounding wrapper for thread-safe data collections
US20090307669A1 (en) * 2008-06-06 2009-12-10 Garst Jr Gerald Blaine Memory management for closures
US7694302B1 (en) * 2001-04-05 2010-04-06 Network Appliance, Inc. Symmetric multiprocessor synchronization using migrating scheduling domains
US7856636B2 (en) 2005-05-10 2010-12-21 Hewlett-Packard Development Company, L.P. Systems and methods of sharing processing resources in a multi-threading environment
US8027925B1 (en) * 1997-07-28 2011-09-27 Apple Inc. System method and apparatus for authorizing access
US20120030649A1 (en) * 2010-08-02 2012-02-02 Advanced Bionics AG, c/o Froriep Renggli Methods and Systems for Automatic Generation of Multithread-Safe Software Code
US8245207B1 (en) 2003-07-31 2012-08-14 Netapp, Inc. Technique for dynamically restricting thread concurrency without rewriting thread code
WO2012141952A1 (en) * 2011-04-15 2012-10-18 Siemens Product Lifecycle Management Software Inc. System and method for execution on multiple threads
US8312249B1 (en) * 2008-10-10 2012-11-13 Apple Inc. Dynamic trampoline and structured code generation in a signed code environment
US8627331B1 (en) 2010-04-30 2014-01-07 Netapp, Inc. Multi-level parallelism of process execution in a mutual exclusion domain of a processing system
WO2015140997A1 (en) * 2014-03-20 2015-09-24 三菱電機株式会社 Program management device and program management method and program
CN112162790A (en) * 2020-09-22 2021-01-01 爱瑟福信息科技(上海)有限公司 API dynamic calling method and system

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4663709A (en) * 1983-10-07 1987-05-05 Nec Corporation Control system for tightly-coupled multiprocessing units
US4847754A (en) * 1985-10-15 1989-07-11 International Business Machines Corporation Extended atomic operations
US5047919A (en) * 1986-04-03 1991-09-10 Harris Corporation Method and apparatus for monitoring software execution in a parallel multiprocessor computer system
US5109511A (en) * 1988-05-31 1992-04-28 Hitachi, Ltd. Shared resource managing method and system
US5226143A (en) * 1990-03-14 1993-07-06 International Business Machines Corporation Multiprocessor system includes operating system for notifying only those cache managers who are holders of shared locks on a designated page by global lock manager
US5230070A (en) * 1989-09-08 1993-07-20 International Business Machines Corporation Access authorization table for multi-processor caches
US5305448A (en) * 1990-07-02 1994-04-19 International Business Machines Corp. Shared access serialization featuring second process lock steal and subsequent write access denial to first process
US5339415A (en) * 1990-06-11 1994-08-16 Cray Research, Inc. Dual level scheduling of processes to multiple parallel regions of a multi-threaded program on a tightly coupled multiprocessor computer system
US5339427A (en) * 1992-03-30 1994-08-16 International Business Machines Corporation Method and apparatus for distributed locking of shared data, employing a central coupling facility
US5353418A (en) * 1989-05-26 1994-10-04 Massachusetts Institute Of Technology System storing thread descriptor identifying one of plural threads of computation in storage only when all data for operating on thread is ready and independently of resultant imperative processing of thread
US5375241A (en) * 1992-12-21 1994-12-20 Microsoft Corporation Method and system for dynamic-link library

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4663709A (en) * 1983-10-07 1987-05-05 Nec Corporation Control system for tightly-coupled multiprocessing units
US4847754A (en) * 1985-10-15 1989-07-11 International Business Machines Corporation Extended atomic operations
US5047919A (en) * 1986-04-03 1991-09-10 Harris Corporation Method and apparatus for monitoring software execution in a parallel multiprocessor computer system
US5109511A (en) * 1988-05-31 1992-04-28 Hitachi, Ltd. Shared resource managing method and system
US5353418A (en) * 1989-05-26 1994-10-04 Massachusetts Institute Of Technology System storing thread descriptor identifying one of plural threads of computation in storage only when all data for operating on thread is ready and independently of resultant imperative processing of thread
US5230070A (en) * 1989-09-08 1993-07-20 International Business Machines Corporation Access authorization table for multi-processor caches
US5226143A (en) * 1990-03-14 1993-07-06 International Business Machines Corporation Multiprocessor system includes operating system for notifying only those cache managers who are holders of shared locks on a designated page by global lock manager
US5339415A (en) * 1990-06-11 1994-08-16 Cray Research, Inc. Dual level scheduling of processes to multiple parallel regions of a multi-threaded program on a tightly coupled multiprocessor computer system
US5305448A (en) * 1990-07-02 1994-04-19 International Business Machines Corp. Shared access serialization featuring second process lock steal and subsequent write access denial to first process
US5339427A (en) * 1992-03-30 1994-08-16 International Business Machines Corporation Method and apparatus for distributed locking of shared data, employing a central coupling facility
US5375241A (en) * 1992-12-21 1994-12-20 Microsoft Corporation Method and system for dynamic-link library

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Memory Protection Software Facility for OS/2 Shared Data Applications", IBM Technical Disclosure Bulletin, vol. 34, No. 4A, Sep. 1991, pp. 81-89.
Memory Protection Software Facility for OS/2 Shared Data Applications , IBM Technical Disclosure Bulletin, vol. 34, No. 4A, Sep. 1991, pp. 81 89. *

Cited By (150)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5832265A (en) * 1993-03-22 1998-11-03 Siemens Nixdorf Informationssysteme Aktiengesellschaft Reentrant libraries
US6148325A (en) * 1994-06-30 2000-11-14 Microsoft Corporation Method and system for protecting shared code and data in a multitasking operating system
US20070089100A1 (en) * 1994-11-16 2007-04-19 Morris Robert M Visually oriented computer implemented application development system utilizing standardized objects and multiple views
US8621432B2 (en) 1994-11-16 2013-12-31 Google Inc. Visually oriented computer implemented application development system utilizing standardized objects and multiple views
US7185316B1 (en) * 1994-11-16 2007-02-27 Morris Robert M Visually oriented computer implemented application development system utilizing standardized objects and multiple views
US5822588A (en) * 1995-06-09 1998-10-13 Sun Microsystem, Inc. System and method for checking the use of synchronization locks in a multi-threaded target program
US5630136A (en) * 1995-06-09 1997-05-13 Sun Microsystems, Inc. Method and apparatus for serializing access to multithreading unsafe resources
US6131188A (en) * 1995-12-22 2000-10-10 Sun Microsystems, Inc. System and method for reducing the occurrence of window use overflow
US6135650A (en) * 1995-12-22 2000-10-24 Sun Microsystems, Inc. Method and system for wrapper routine optimization
US5901317A (en) * 1996-03-25 1999-05-04 Sun Microsystems, Inc. Method and system for register allocation using multiple interference graphs
US6760909B1 (en) * 1996-04-29 2004-07-06 Microsoft Corporation Virtual memory system and methods
US5901316A (en) * 1996-07-01 1999-05-04 Sun Microsystems, Inc. Float register spill cache method, system, and computer program product
US6275871B1 (en) * 1996-07-03 2001-08-14 Siemens Aktiengesellschaft Asynchronous transport optimizing observer-pattern-like system supporting several modes for an interface definition language-less communication subsystem
US6173309B1 (en) * 1997-02-20 2001-01-09 Hewlett-Packard Company Null thread library and thread abstraction interface
US5938743A (en) * 1997-03-17 1999-08-17 Xerox Corporation Method of using the UNIX physio to allow data to be transferred on a plurality of channels concurrently
US6996826B2 (en) 1997-05-14 2006-02-07 Microsoft Corporation Method and system for accessing objects of different thread types
US6415334B1 (en) * 1997-05-14 2002-07-02 Microsoft Corporation Method and system for accessing objects of different thread types
US20020055965A1 (en) * 1997-05-14 2002-05-09 Microsoft Corporation Method and system for accessing objects of different thread types
US6139200A (en) * 1997-06-30 2000-10-31 Sun Microsystems, Inc. Register resource allocation feedback
US6009272A (en) * 1997-06-30 1999-12-28 Sun Microsystems, Inc. Register allocation via selective spilling
US5987259A (en) * 1997-06-30 1999-11-16 Sun Microsystems, Inc. Functional unit switching for the allocation of registers
US20020059358A1 (en) * 1997-07-17 2002-05-16 Microsoft Corporation Method and system for accessing objects of different thread types
US6981255B2 (en) 1997-07-17 2005-12-27 Microsoft Corporation Method and system for accessing objects of different thread types
US6006278A (en) * 1997-07-18 1999-12-21 Electronic Data Systems Corporation Method and system for importing remote functions to a network computer
US5958028A (en) * 1997-07-22 1999-09-28 National Instruments Corporation GPIB system and method which allows multiple thread access to global variables
US20120066135A1 (en) * 1997-07-28 2012-03-15 Apple Inc., a California corporation Method and Apparatus for Enforcing Software Licenses
US8027925B1 (en) * 1997-07-28 2011-09-27 Apple Inc. System method and apparatus for authorizing access
US8781971B2 (en) * 1997-07-28 2014-07-15 Apple Inc. Method and apparatus for enforcing software licenses
US20130179989A1 (en) * 1997-07-28 2013-07-11 Apple Inc. Method and apparatus for enforcing software licenses
US8452712B2 (en) * 1997-07-28 2013-05-28 Apple Inc. Method and apparatus for enforcing software licenses
US6189023B1 (en) * 1997-09-30 2001-02-13 Tandem Computers Incorporated Simulating shared code thread modules with shared code fibers
US6405264B1 (en) 1997-12-18 2002-06-11 Sun Microsystems, Inc. Marshaling and unmarshaling framework for supporting filters in a distributed object system
US6249803B1 (en) 1997-12-18 2001-06-19 Sun Microsystems, Inc. Method and apparatus for executing code during method invocation
US6510460B1 (en) * 1997-12-18 2003-01-21 Sun Microsystems, Inc. Method and apparatus for enforcing locking invariants in multi-threaded systems
US6516354B2 (en) 1997-12-18 2003-02-04 Sun Microsystems, Inc. Method and apparatus for efficient representation of variable length identifiers in a distributed object system
US6490609B1 (en) * 1998-01-09 2002-12-03 Sun Microsystems, Inc. Method, apparatus and computer program product for invoking a thread-unaware routine that uses an operation-dependent temporary data structure
US6490617B1 (en) * 1998-06-09 2002-12-03 Compaq Information Technologies Group, L.P. Active self discovery of devices that participate in a network
US6112222A (en) * 1998-08-25 2000-08-29 International Business Machines Corporation Method for resource lock/unlock capability in multithreaded computer environment
US6105050A (en) * 1998-08-25 2000-08-15 International Business Machines Corporation System for resource lock/unlock capability in multithreaded computer environment
US6105049A (en) * 1998-08-25 2000-08-15 International Business Machines Corporation Resource lock/unlock capability in multithreaded computer environment
US6622155B1 (en) 1998-11-24 2003-09-16 Sun Microsystems, Inc. Distributed monitor concurrency control
US6295611B1 (en) 1998-12-14 2001-09-25 Sun Microsystems, Inc.. Method and system for software recovery
US6430703B1 (en) 1998-12-14 2002-08-06 Sun Microsystems, Inc. Method and system for software recovery
US6684394B1 (en) * 1999-09-03 2004-01-27 Stmicroelectronics Limited Relocation format for linking with relocation instructions containing operations for combining section data
US6782537B1 (en) 1999-09-23 2004-08-24 International Business Machines Corporation Establishing a communicator across multiple processes in a multithreaded computing environment
US6996808B1 (en) * 2000-02-12 2006-02-07 Microsoft Corporation Function injector
US7487152B1 (en) 2000-05-31 2009-02-03 International Business Machines Corporation Method for efficiently locking resources of a global data repository
US8108451B2 (en) 2000-05-31 2012-01-31 International Business Machines Corporation System and program products for efficiently locking resources of a global data repository
US20090171963A1 (en) * 2000-05-31 2009-07-02 International Business Machines Corporation System and program products for efficiently locking resources of a global data repository
US6851114B1 (en) * 2000-11-06 2005-02-01 Sun Microsystems, Inc. Method for improving the performance of safe language multitasking
US20040111720A1 (en) * 2001-02-01 2004-06-10 Vertes Marc Philippe Method and system for managing shared-library executables
US7506316B2 (en) * 2001-02-01 2009-03-17 International Business Machines Corporation Method and system for managing shared-library executables
US7178137B1 (en) 2001-04-05 2007-02-13 Network Appliance, Inc. Automatic verification of scheduling domain consistency
US7694302B1 (en) * 2001-04-05 2010-04-06 Network Appliance, Inc. Symmetric multiprocessor synchronization using migrating scheduling domains
US7143407B2 (en) 2001-07-26 2006-11-28 Kyocera Wireless Corp. System and method for executing wireless communications device dynamic instruction sets
US20030064717A1 (en) * 2001-07-26 2003-04-03 Gowri Rajaram System and method for the management of wireless communications device system software downloads in the field
US20030066064A1 (en) * 2001-07-26 2003-04-03 Gowri Rajaram System and method for field diagnosis of wireless communications device system software
US20050064847A1 (en) * 2001-07-26 2005-03-24 Bilhan Kirbas System and method for over the air area code update
US6918108B2 (en) 2001-07-26 2005-07-12 Kyocera Wireless Corp. System and method for field diagnosis of wireless communications device system software
US8032865B2 (en) 2001-07-26 2011-10-04 Kyocera Corporation System and method for field diagnosis of wireless communications device system software
US20030069007A1 (en) * 2001-07-26 2003-04-10 Gowri Rajaram System and method for updating persistent data in a wireless communications device
US20030022663A1 (en) * 2001-07-26 2003-01-30 Gowri Rajaram System and method for field downloading a wireless communications device software code section
US20050245248A1 (en) * 2001-07-26 2005-11-03 Gowri Rajaram System and method for field diagnosis of wireless communications device system software
US20050026603A9 (en) * 2001-07-26 2005-02-03 Gowri Rajaram System and method for the management of wireless communications device system software downloads in the field
US20050010917A9 (en) * 2001-07-26 2005-01-13 Gowri Rajaram System and method for executing wireless communications device dynamic instruction sets
US20040214559A1 (en) * 2001-07-26 2004-10-28 Kyocera Wireless Corp. System and method for interchangeable modular hardware components for wireless communication devices
US7577126B2 (en) 2001-07-26 2009-08-18 Kyocera Wireless Corp. System and method for over the air area code update
US7027806B2 (en) 2001-07-26 2006-04-11 Kyocera Wireless, Corp. System and method for field downloading a wireless communications device software code section
US7542758B2 (en) 2001-07-26 2009-06-02 Kyocera Wireless Corp. Field downloading of wireless device software
US7970375B2 (en) 2001-07-26 2011-06-28 Kyocera Corporation System and method for expiring modular software components for wireless communication devices
US20030022665A1 (en) * 2001-07-26 2003-01-30 Gowri Rajaram System and method for organizing field upgradable wireless communication device software
US7328007B2 (en) * 2001-07-26 2008-02-05 Kyocera Wireless Corp. System and method for organizing wireless communication device system software
US20060223517A1 (en) * 2001-07-26 2006-10-05 Kyocera Wireless Corp. Field downloading of wireless device software
US20040214560A1 (en) * 2001-07-26 2004-10-28 Kyocera Wireless Corp. Modular software components for wireless communication devices
US7159214B2 (en) 2001-07-26 2007-01-02 Kyocera Wireless Corp. System and method for compacting field upgradeable wireless communication device software code sections
US20040214561A1 (en) * 2001-07-26 2004-10-28 Kyocera Wireless Corp. Dynamic interface software for wireless communication devices
US7184759B2 (en) 2001-07-26 2007-02-27 Kyocera Wireless Corp. Modular software components for wireless communication devices
US7184793B2 (en) 2001-07-26 2007-02-27 Kyocera Wireless Corp. System and method for over the air area code update
US20040205746A9 (en) * 2001-07-26 2004-10-14 Gowri Rajaram System and method for field diagnosis of wireless communications device system software
US7197302B2 (en) 2001-07-26 2007-03-27 Kyocera Wireless Corp. System and method for interchangeable modular hardware components for wireless communication devices
US7200389B2 (en) 2001-07-26 2007-04-03 Kyocera Wireless Corp. Dynamic interface software for wireless communication devices
US9554268B2 (en) 2001-07-26 2017-01-24 Kyocera Corporation System and method for updating persistent data in a wireless communications device
US20030033599A1 (en) * 2001-07-26 2003-02-13 Gowri Rajaram System and method for executing wireless communications device dynamic instruction sets
US20070143749A1 (en) * 2001-07-26 2007-06-21 Date Umesh M System and method for expiring modular software components for wireless communication devices
US20070140200A1 (en) * 2001-07-26 2007-06-21 Bilhan Kirbas System and method for over the air area code update
US7386846B2 (en) 2001-07-26 2008-06-10 Kyocera Wireless Corp. System and method for the management of wireless communications device system software downloads in the field
US8479180B2 (en) 2001-07-26 2013-07-02 Kyocera Corporation Maintenance of over the air upgradeable wireless communication device software
US20060063519A1 (en) * 2001-08-10 2006-03-23 Gowri Rajaram System and method for peer-to-peer handset communication
US20030110480A1 (en) * 2001-08-10 2003-06-12 Gowri Rajaram System and method for peer-to-peer handset communication
US6961537B2 (en) 2001-08-10 2005-11-01 Kyocera Wireless Corp. System and method for peer-to-peer handset communication
US20030110479A1 (en) * 2001-08-10 2003-06-12 Gowri Rajaram System and method for bi-directional communication and execution of dynamic instruction sets
US7359699B2 (en) 2001-08-10 2008-04-15 Kyocera Wireless Corp. System and method for peer-to-peer handset communication
US7254386B2 (en) 2001-08-10 2007-08-07 Kyocera Wireless Corp. System and method for improved security in handset reprovisioning and reprogramming
US7117494B2 (en) 2001-08-10 2006-10-03 Kyocera Wireless Corp. System and method for bi-directional communication and execution of dynamic instruction sets
US20030033525A1 (en) * 2001-08-10 2003-02-13 Gowri Rajaram System and method for improved security in handset reprovisioning and reprogramming
US20030182572A1 (en) * 2001-12-06 2003-09-25 Cowan Stanley Crispin Pointguard: method and system for protecting programs against pointer corruption attacks
US20080060077A1 (en) * 2001-12-06 2008-03-06 Novell, Inc. Pointguard: method and system for protecting programs against pointer corruption attacks
US8631248B2 (en) * 2001-12-06 2014-01-14 Apple Inc. Pointguard: method and system for protecting programs against pointer corruption attacks
US7752459B2 (en) 2001-12-06 2010-07-06 Novell, Inc. Pointguard: method and system for protecting programs against pointer corruption attacks
US20030233430A1 (en) * 2002-06-13 2003-12-18 International Business Machines Corporation Method of modifying a logical library configuration from a remote management application
US7047286B2 (en) 2002-06-13 2006-05-16 International Business Machines Corporation Method of modifying a logical library configuration from a remote management application
US7117498B2 (en) * 2002-06-14 2006-10-03 Intel Corporation Thread optimization for lock and unlock operations in a multi-thread environment
US20030233393A1 (en) * 2002-06-14 2003-12-18 Xiao-Feng Li Thread optimization for lock and unlock operations in a multi-thread environment
US8245207B1 (en) 2003-07-31 2012-08-14 Netapp, Inc. Technique for dynamically restricting thread concurrency without rewriting thread code
US20050039187A1 (en) * 2003-08-12 2005-02-17 Avakian Arra E. Instrumenting java code by modifying bytecodes
US7484209B2 (en) * 2003-08-12 2009-01-27 Hewlett-Packard Development Company, L.P. Instrumenting java code by modifying bytecodes
US20050066303A1 (en) * 2003-09-22 2005-03-24 Trigence Corp. Computing system having user mode critical system elements as shared libraries
US7784058B2 (en) * 2003-09-22 2010-08-24 Trigence Corp. Computing system having user mode critical system elements as shared libraries
US8171480B2 (en) 2004-01-27 2012-05-01 Network Appliance, Inc. Method and apparatus for allocating shared resources to process domains according to current processor utilization in a shared resource processor
US20050172293A1 (en) * 2004-01-27 2005-08-04 Network Appliance, Inc. Method and apparatus for allocating resources in a shared resource processor
US10613858B2 (en) 2004-03-31 2020-04-07 Intel Corporation Method and system to provide user-level multithreading
US10628153B2 (en) 2004-03-31 2020-04-21 Intel Corporation Method and system to provide user-level multithreading
US10585667B2 (en) 2004-03-31 2020-03-10 Intel Corporation Method and system to provide user-level multithreading
US10635438B2 (en) 2004-03-31 2020-04-28 Intel Corporation Method and system to provide user-level multithreading
US20050223199A1 (en) * 2004-03-31 2005-10-06 Grochowski Edward T Method and system to provide user-level multithreading
US9952859B2 (en) 2004-03-31 2018-04-24 Intel Corporation Method and system to provide user-level multithreading
US9442721B2 (en) 2004-03-31 2016-09-13 Intel Corporation Method and system to provide user-level multithreading
US9189230B2 (en) 2004-03-31 2015-11-17 Intel Corporation Method and system to provide concurrent user-level, non-privileged shared resource thread creation and execution
US7577889B1 (en) * 2004-09-16 2009-08-18 At&T Intellectual Property Ii, L.P. Method for detecting software errors and vulnerabilities
US7293213B1 (en) * 2004-09-16 2007-11-06 At&T Corp. Method for detecting software errors and vulnerabilities
US20060200809A1 (en) * 2005-03-03 2006-09-07 Nikola Grcevski Transforming code to expose glacial constants to a compiler
US7698697B2 (en) 2005-03-03 2010-04-13 International Business Machines Corporation Transforming code to expose glacial constants to a compiler
US7856636B2 (en) 2005-05-10 2010-12-21 Hewlett-Packard Development Company, L.P. Systems and methods of sharing processing resources in a multi-threading environment
US8347293B2 (en) 2005-10-20 2013-01-01 Network Appliance, Inc. Mutual exclusion domains to perform file system processes on stripes
US20070094529A1 (en) * 2005-10-20 2007-04-26 Lango Jason A Method and apparatus for increasing throughput in a storage server
US20070240135A1 (en) * 2006-03-09 2007-10-11 Stoodley Kevin A Programmatic compiler optimization of glacial constants
US7840950B2 (en) * 2006-03-09 2010-11-23 International Business Machines Corporation Programmatic compiler optimization of glacial constants
US20080209432A1 (en) * 2006-06-15 2008-08-28 Guruduth Somasekhara Banavar Computer implemented method and system for sharing resources among hierarchical containers of resources
US8423956B2 (en) * 2006-06-15 2013-04-16 International Business Machines Corporation Sharing resources among hierarchical containers of resources
US20070291124A1 (en) * 2006-06-20 2007-12-20 David Staudacher Event management for camera systems
US8089516B2 (en) * 2006-06-20 2012-01-03 Hewlett-Packard Development Company, L.P. Event management for camera systems
US8413173B2 (en) * 2008-01-07 2013-04-02 Dell Products L.P. Method, apparatus and system for automatic loading of a network stack
US20090178060A1 (en) * 2008-01-07 2009-07-09 Dell Products L.P. Method, Apparatus and System for Automatic Loading of a Network Stack
US8448154B2 (en) * 2008-02-04 2013-05-21 International Business Machines Corporation Method, apparatus and software for processing software for use in a multithreaded processing environment
US20090198968A1 (en) * 2008-02-04 2009-08-06 Colin Penfold Method, Apparatus and Software for Processing Software for Use in a Multithreaded Processing Environment
US8356308B2 (en) 2008-06-02 2013-01-15 Microsoft Corporation Blocking and bounding wrapper for thread-safe data collections
WO2009148740A3 (en) * 2008-06-02 2010-02-18 Microsoft Corporation Blocking and bounding wrapper for thread-safe data collections
CN102047222A (en) * 2008-06-02 2011-05-04 微软公司 Blocking and bounding wrapper for thread-safe data collections
US20090300766A1 (en) * 2008-06-02 2009-12-03 Microsoft Corporation Blocking and bounding wrapper for thread-safe data collections
US20090307669A1 (en) * 2008-06-06 2009-12-10 Garst Jr Gerald Blaine Memory management for closures
US8312249B1 (en) * 2008-10-10 2012-11-13 Apple Inc. Dynamic trampoline and structured code generation in a signed code environment
US20130067246A1 (en) * 2008-10-10 2013-03-14 Apple Inc. Dynamic Trampoline and Structured Code Generation in a Signed Code Environment
US8700880B2 (en) * 2008-10-10 2014-04-15 Apple Inc. Dynamic trampoline and structured code generation in a signed code environment
US8627331B1 (en) 2010-04-30 2014-01-07 Netapp, Inc. Multi-level parallelism of process execution in a mutual exclusion domain of a processing system
US9071622B2 (en) 2010-04-30 2015-06-30 Netapp, Inc. Multi-level parallelism of process execution in a mutual exclusion domain of a processing system
WO2012018666A1 (en) * 2010-08-02 2012-02-09 Advanced Bionics Ag Methods and systems for automatic generation of multithread-safe software code
US20120030649A1 (en) * 2010-08-02 2012-02-02 Advanced Bionics AG, c/o Froriep Renggli Methods and Systems for Automatic Generation of Multithread-Safe Software Code
WO2012141952A1 (en) * 2011-04-15 2012-10-18 Siemens Product Lifecycle Management Software Inc. System and method for execution on multiple threads
WO2015140997A1 (en) * 2014-03-20 2015-09-24 三菱電機株式会社 Program management device and program management method and program
CN112162790A (en) * 2020-09-22 2021-01-01 爱瑟福信息科技(上海)有限公司 API dynamic calling method and system

Similar Documents

Publication Publication Date Title
US5481706A (en) System and method for creating thread-safe shared libraries
US5953530A (en) Method and apparatus for run-time memory access checking and memory leak detection of a multi-threaded program
Chin et al. Distributed, object-based programming systems
Bogle et al. Reducing cross domain call overhead using batched futures
US9189263B1 (en) Object synchronization in shared object space
JP2575541B2 (en) Invalidation method of hierarchy of distributed cache
US5727203A (en) Methods and apparatus for managing a database in a distributed object operating environment using persistent and transient cache
US5915253A (en) Method and system for implementing objects in a storage system
US6766471B2 (en) User-level checkpoint and restart for groups of processes
US6473806B1 (en) Methods and apparatus for managing objects and processes in a distributed object operating environment
Russo An object-oriented operating system
US6199094B1 (en) Protecting shared resources using mutex striping
US7747996B1 (en) Method of mixed lock-free and locking synchronization
McJones et al. Evolving the UNIX system interface to support multithreaded programs
Drepper Futexes are tricky
US6223335B1 (en) Platform independent double compare and swap operation
Khalidi et al. The Spring virtual memory system
US7451434B1 (en) Programming with shared objects in a shared memory
US5692187A (en) Shadow mechanism having masterblocks for a modifiable object oriented system
Myers et al. A hardware implementation of capability-based addressing
KR19980079611A (en) Mechanism for locking tool data objects in the framework environment
Pollack et al. The iMAX-432 object filing system
US6408305B1 (en) Access frontier for demand loading pages in object-oriented databases
Divacky Linux® emulation in FreeBSD
Mathiske et al. Automatic Persistent Memory Management for the Spotless [tm] Virtual Machine on the Palm Connected Organizer

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PEEK, JEFFREY S.;REEL/FRAME:006755/0916

Effective date: 19931029

FPAY Fee payment

Year of fee payment: 4

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 8

SULP Surcharge for late payment

Year of fee payment: 7

REMI Maintenance fee reminder mailed
REMI Maintenance fee reminder mailed
LAPS Lapse for failure to pay maintenance fees
STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20080102