Single DLL for multiple devices using the same driver

Question

I try to design a third-party DLL between user application and driver, which will be able to manage communication with multiple devices (of the same model) connected via PCIe to the same PC. A single DLL will be placed in known folder, e.g. %SystemRoot%/System32. Loading / Unloading DLL should call some functions, eg. FindDevices(), OpenDevice(), CloseDevice() which will update struct defined in DLL, eg. DeviceManager:

const int MAX_DEV_INSTANCES;

typedef struct DEV_STATUS_T {

    BOOL swConnected;           // State of SW connection
    UINT32 swConnIdx;           // ID of SW app

    BOOL hwConnected;           // State of HW connection
    UINT32 hwPortIdx;           // ID of port for HW

} DEV_STATUS;

typedef struct DEV_MANAGER_T {

    UINT32 devicesNr;
    DEV_STATUS status[MAX_DEV_INSTANCES];
    DEVICE device[MAX_DEV_INSTANCES];

} MANAGER;

MANAGER manager;

Let's assume we have 2 devices: A, B and 2 applications: M, N. They both try to connect to a single, separate device: M controls A, N controls B.

My questions:

1. Assume M loads DLL and DLL updates MANAGER struct {status[0], device[0]}. If N loads the same DLL, will it be able to see that M made change in {status[0], device[0]} or M, N will have separate copies of MANAGER structs to deal with?

2. If M and N are not aware of external changes made in MANAGER (MANAGER is not 'global'), what is the way to achieve this? Should it be managed in lower layer - driver code?

3. If M and N are aware of external changes made in MANAGER (MANAGER is 'global'), will OpenDevice() / CloseDevice() be the only functions that need to modify MANAGER struct?

Thank you for any comments and suggestions on this matter.

Answer 1

Here are some pointers :

1. No, both applications will be in different memory space, so modifications made to MANAGER by application M won't have any effect on application N
2. Several solutions, but beware of concurrency in any of those :
   1. Use shared memory buffer for the data
   2. Put the manager in a separate process (this could be the driver if you have access to it)
   3. Use file locks to represent that a device is "owned" by a process
3. Don't know...