Encapsulate communication with serial device in a DLL

[NathanJD]

I have a situation where we have created a device that uses serial communication and we need to be able to communicate with it from multiple applications (LabVIEW and non-LabVIEW).  Because it's two-way serial communication, I need to be able to serialize all command being sent to it (so I don't have a race condition with response packets from the device).

I was hoping that I would be able to create a DLL in LabVIEW (since the other group needing to communicate with it knows how to use LabVIEW-built DLLs already) that would encapsulate the communication and allow me to control, or effectively serialize, the commands being sent to the device.  I have a few questions.

Is it possible for two applications to use the same DLL?

If two independent applications instatiate the same DLL, are the functions that are called inherently serialized?

If not, can I serialize them by using a semaphore in the DLL to control the access to the serial device?

I'm guessing it has to do with multithreading capabilities (which I'm not all that familiar with) and the access scope of global variabls/FGVs in the DLL when used by multple applications.

Any help or suggestions are appreciated.

[tyk007]

---

@NathanJD wrote:

I have a situation where we have created a device that uses serial communication and we need to be able to communicate with it from multiple applications (LabVIEW and non-LabVIEW).  Because it's two-way serial communication, I need to be able to serialize all command being sent to it (so I don't have a race condition with response packets from the device).

I was hoping that I would be able to create a DLL in LabVIEW (since the other group needing to communicate with it knows how to use LabVIEW-built DLLs already) that would encapsulate the communication and allow me to control, or effectively serialize, the commands being sent to the device.  I have a few questions.

Is it possible for two applications to use the same DLL?

If two independent applications instatiate the same DLL, are the functions that are called inherently serialized?

If not, can I serialize them by using a semaphore in the DLL to control the access to the serial device?

I'm guessing it has to do with multithreading capabilities (which I'm not all that familiar with) and the access scope of global variabls/FGVs in the DLL when used by multple applications.

Any help or suggestions are appreciated.

---

Maybe someone with a bit more expereicen can comment on this but my gut feel, based on baisc Win32 dll usage is:

Is it possible for two applications to use the same DLL? Yes. They are loaded into each seperate memory space

If two independent applications instatiate the same DLL, are the functions that are called inherently serialized? No

If not, can I serialize them by using a semaphore in the DLL to control the access to the serial device? Do you mean LabVIEW Semaphore? I don't believe so. Semaphores (and the Queues they are built upon) are only unique per application instance. The LV runtime will most likely be hosted per application; thus the semaphore is only unique per application. There are other ways of providing cross-process syncronisation though (https://msdn.microsoft.com/en-us/library/windows/desktop/ms684123(v=vs.85).aspx). 

I alos beleve that once a COM port handle is opened and used by one process that it is inaccessible to another process unless you do some tricky things behind the scenes (which I don't recommend). I think the easiest option here is to have a device "server" application that connects to the device and exposes, via TCP, the ability for clients to connect and use the device. This lets you implement the locking where you need it (at the device server).

[NathanJD]

 Thanks for the response!

---

@Thanks for the tyk007 wrote:

I alos beleve that once a COM port handle is opened and used by one process that it is inaccessible to another process unless you do some tricky things behind the scenes (which I don't recommend). I think the easiest option here is to have a device "server" application that connects to the device and exposes, via TCP, the ability for clients to connect and use the device. This lets you implement the locking where you need it (at the device server).

---

Yes.  If you open the Virtual COM port resource, it will be unavailable to other applications.  Now that you mention that, I realized that I can actually use that to my advantage:  have each command open the COM port when it starts and close it when finished (where when you go to open it, you would wait until it's available).  This will probably work well for my application since we don't intend on ever needing to talk to it very quickly or often (luckily).