GB2418750A - DLL component having export function through an interface - Google Patents

Abstract

The present invention provides for a DLL component, encapsulated within a class, and having an export function provided with a pointer to an interface of the said class, the functionality of the DLL component being standardised to an sufficient extent to allow loading of the DLL and the provision of the said pointer, to be encapsulated, such that just one export function is then provided that returns the pointer to an interface that can support all required behaviour. Furthermore, the encapsulating class is preferably instantiated as a thread local singleton, resulting in the DLL component being rendered thread-safe.

Description

24 1 8750 Thread Local Singleton Dvnamic Link Library Component and Method

of Forming the Same The present invention relates to Dynamic Link Library (DLL) components and to a method of forming the same.

As is currently known, DLL components forming a system are generally arranged to interact with each other, for example by conducting calling functions on each other.

It is found however that such interaction can often prove relatively problematic since each DLL first has to be loaded, and then the required export function address obtained, before the actual function of the DLL can be invoked.

Such problems and limitations become much more pronounced when the process concerned comprises multiple threads each trying to use the DLL independently from each other.

As will be appreciated, since a DLL cannot have multiple instances within the memory space provided for a process, the access and usage of the DLL data by one thread is likely to have the effect of invalidating the DLL data for use by any other thread.

Multithreading, therefore, creates problems which must be resolved.

Although mechanisms seeking to make a system comprising DLLs available for multithreading are known, they are however disadvantageously difficult to implement. Such difficulties are found to arise since a standard ("Regular") DLL does not have the capability of providing thread attach/detach notifications and, also, standard thread-local mechanisms, such as_decispec (thread) or TLSAllocO. used on different classes do not have the capability of invoking constructors nor destructors.

To compensate for such problems, it is required that the host application notifies the DLL, generally by way of specialized export functions, immediately after a new thread calls for a "LoadLibrary" instruction, and immediately before a thread calls a "FreeLibrary" instruction. In this manner it would then prove possible for the DLL to initialise and sort its thread-local objects.

The present invention seeks to provide for a DLL component, and method of forming the same, having advantages over known such components and methods.

According to a first aspect of the present invention, there is provided a DLL component, encapsulated within a class, and having an export function provided with a pointer to an interface of the said class, the functionality of the DLL component being standardised to an extent to allow loading of the DLL and the provision of the said pointer to be encapsulated.

The present invention is advantageous in removing the difficulties otherwise experienced when DLLs seek to interact with one another.

The invention is further advantageous in that, as compared with the priorart, just one export function is provided that returns the pointer to an interface that can support all required behaviour, as compared with the provision of a plurality of export functions each supporting a single prior-art of all of the required behaviour.

The present invention is then further distinguished from the prior-art in that the object implementing the interface is declared as a thread-local singleton and so a new instance of this object is created for each thread, as compared with many threads using the same object as arises in the prior-art.

Then, since each component can then produce a thread-local singleton, the system is made advantageously internally thread-safe. As such, every new thread that accesses the system, serves to initiate a new and independent singleton for each DLL component.

In this manner there can be provided thread-local singleton DLL components in which each thread entering the system initiates new component objects. Advantageously therefore, the use of the system by one thread does not interfere with the use of the system by another thread.

The disadvantages discussed above in relation to the current state of the art can therefore be readily overcome in an effective and efficient manner.

According to another aspect of the present invention, there is provided a method of forming a DLL component including the steps of encapsulating the functionality of the DLL component within a class, providing a pointer to an interface of this class within an export function of the DLL, and wherein the functionality of the DLL component is standardised such that the loading of the DLL, and the provision of the pointer to the said interface can be encapsulated.

Advantageously, the class that encapsulates the DLL component is arranged to employ a non-standard, undocumented MFC mechanism.

Such mechanism can comprise a "CThreadLocal" template.

This comprises an advantageously simple mechanism that cannot only provide the thread-local class objects, but can also call for their constructors and destructors.

Again, combining the aforementioned features advantageously provides for a thread-local singleton DLL components in which each thread entering the system can instantiate new component objects such that the use of the system by one thread does not interfere with the use of the system by another thread.

The invention is described further hereinafter by way of a particular example of the implementation of an aspect of the invention in the formation of a thread-local singleton DLL component.

First, each component class is derived from an abstract interface class and is declared as a "CThreadlocal" object.

Each DLL component is arranged to then provide one export function only, which export function is arranged to return a pointer to the aforementioned abstract interface class. It should of course be appreciated here that each DLL's component interface should be unique.

A particular class identified as "CDLLProvider" is arranged to encapsulate the process of locating and loading a DLL and calling the particular export function of that DLL in order to obtain the pointer to the DLL component's interface.

Any class that might require a pointer to a DLL component then simply has to declare "CDLLProvider" as a member and so then invoke "CDLLProvider" as required.

Advantageously, "CDLLProvider" maintains a count of the number of times "LoadLibrary" is called on the DLL and, within its destructor, is arranged to call "FreeLibrary" the corresponding number of times.

It is however appreciated that a relatively small overhead arises here as multiple instances of "CDLLProvider" will be calling "LoadLibrary" and "GetProcAdress" to obtain the same DLL interface pointers. However, any such overhead can advantageously, and simply, be minimised by determining that each class requiring a DLL interface should be controlled to invoke "CDLLProvider" just once, on initialization, and then retain a pointer to the interface for future use.

Thus, it will be appreciated that the present invention provides for a mechanism whereby each DLL component in the system is provided with one export function offering a pointer to a thread-local singleton.

The thread-local singleton mechanism allows any part of any DLL component to have direct access to another component interface, and without having to provide for thread management of a nature arising in the prior-art.

The present invention advantageously finds particular use in relation to 2G Decoders used, for example, in tools applications such as those known within NEC Corporation as CATS and ASKA. Since, for example, CATS may test a number of mobile phones at the same time (each test occurring on a separate thread), this requires that each threads usage of 2G decoder is independent of any other and this can advantageously be achieved by way of the present invention.

It should however of course be appreciated that the invention is not restricted to the details of the foregoing embodiments.

Claims (1)

1. Claims 1. A DLL component, encapsulated within a class, and having an

   export function provided with a pointer to an interface of the said class, the functionality of the DLL component being standardized to a sufficient extend to allow loading of the DLL and the provision of the said pointer, to be 1 0 encapsulated.

   2. A component as claimed in Claim 1, wherein the encapsulating class is instantiated as a thread-local singleton.

   4. A component as claimed in Claim 2 or 3, wherein thread local class objects are provided by the encapsulation along with their constructors and destructors.

   5. A method of forming a DLL component including the steps of encapsulating the functionality of the DLL component within a class, providing a pointer to an interface of this class within an export function of the DLL, and wherein the functionality of the DLL component is standardised such that the loading of the DLL and the provision of the pointer to the said interface can be encapsulated.

   6. A method as claimed in Claim 5, wherein the class that encapsulates the DLL component is arranged to employ a non-standard, undocumented MFC mechanism.

   7. A method as claimed in Claim 6 wherein the said mechanism can comprise a thread-local template.

   8. A DLL component substantially as hereinbefore described.

   9. A method of forming a DLL component substantially as hereinbefore described.