It has been recognized for decades that reusable code modules provide significant benefits to software development projects, in at least two critical areas. Once a reusable library is implemented and debugged, it is immediately available for subsequent projects and therefore eliminates development time. Secondly, an operational library eliminates uncertainly as to its effectiveness and reliability.
A few years ago, FABNexus developed a transportable library that implements a generic fixed-size message-passing mechanism, in the form of a FIFO queue. This library was designed to facilitate message passing between threads and/or processes running on the same computer system. Internally it used shared memory. The application would specify the queue element size in bytes when creating the queue. The specific content of each queue element was managed entirely by the end-point application users. This message-passing library was implemented on both Windows (WIN32) and LINUX. On a subseqeunt project, this library was easily adapted to function identically with programs running on different inter-networked computer systems. This was accomplished by modifying the libary to utilize TCP/IP sockets, although this was hidden from the application programmer (not entirely, since he/she were required to supply an internet address at queue initialization time).
The current implementation of the inter-networked message-passing library assumes homogenous CPU types at both end-points, but can easily be adapted to support heterogenous computer systems with a relatively modest application interface upgrade. The current implementation requires the application to pass a ‘type-less’ byte-buffer for insertion (’Put’) into the queue, and correspondingly a type-less buffer for removal (’Get’) from the queue. To update the message-passing library to support hetergenous processor (CPU) types at each end-point, the application will be required to utilize library-supplied type-specific GetxxItem() and PutxxItem() methods when inserting and extracting byte-ordered numeric (and other values) from the queue buffer element. These insertion routines will mitigate the effect of differing CPU byte-ordering factors (i.e. big-endian and little-endian matters). For example, the library shall provide for the application’s usage a set of routines such as:
PutI1Item(), PutI2Item(), PutI4Item(), PutI8Item(), PutF4Item(), PutF8Item(), PutU2Item(), PutU4Item(), PutU8Item(). Similarly, there will be GetI1Item(), GetI2Item(), GetI4Item(), GetI8Item(), GetF4Item(), GetF8Item(), GetU2Item(), GetU4Item(), and GetU8Item() methods.
More will be said about this facility in a subsequent blog submittal.
Cheers,
Jerry W. Rice