Hi,
i’m trying to use the FrontPanel API in a threaded application. I have read both in the documentation and in the forum that the FrontPanel API doesn’t support multithreading. You mention that I’d be ok as long as I make all calls to the API (including instantiation of the Device object) from one thread. How about synchronizing the calls to the API with a semaphore or some other synchronization object. Will that allow me to use multiple threads? I could guarantee that there won’t be any nested API calls (by holding a lock before calling any of the API functions). However, making all calls from the same thread seems very restrictive. Is that my only option of not accessing the API from the main thread?
Cheers,
Thomas
Thomas–
Absolutely. Multithreading is encouraged!! The FrontPanel Application itself is multithreaded. Our EVB100X okCameraApp is also multithreaded to read camera data and display in separate threads. Otherwise, the GUI message queue would make things very uncomfortable for the user.
But as you mention, you need to mutex the access to each device. You can have multiple devices open in multiple threads and accessed simultaneously. But accesses to any one particular device must not overlap.
So if i interpret your answer correctly I should be able to access the device from multiple threads as long as I properly synchronize access to it (like you would do with any shared resource in a multi-threaded program). We tried this but got strange errors and unreliable operation whereas a timer driven polling worked just fine. We are in the process of rewriting our application so that only one thread will make calls to the device, all external access to the device is funneled through this thread as you have described in the documentation. This seems overly restrictive but we’ll see if that solves our problems.
Cheers,
Thomas
The solution with only accessing the API from a single thread does work. However, we had to implement quite a bit of plumbing to make this work (a queuing mechanism). However, we are running into issues with performance since for every device access we have to wake up our device thread, schedule the call, wait for it to finish, and continue with our main thread. This becomes prohibitive. Are you planning to support full multi-threading at some point? I.e. make it possible to call a device object from multiple threads and synchronize access using regular locking mechanisms (i.e. no two threads will be accessing the object at the same time)? This seems like a pretty reasonable behavior.
Cheers,
Thomas
Thomas-- I’m not sure I understand why performance would be any difference if we perform the locking versus if you perform the locking and resource management. Can you explain why you see such a performance hit?
Usually the much greater performance hit comes from doing smaller USB transfers. If you’re able to schedule larger USB transfers, the overhead involved in OS-related resource management will be negligible.
It’s been a while and we will review our OK driver model. Our current implementation (which is someonewhat limiting) goes like this:
We access a single device (including opening, all access, and closing) from a single thread. Question:
Can I create a device on one thread and read/write to/from it from another thread? As long as I guarantee to properly synchronize access? We had problems doing so in FP 3.x. But we are now on 5.x and I wonder if this should work with the current drivers.
Cheers,
Thomas
Yes. As long as API calls do not overlap to a specific device, this should be fine.
Thanks for your quick reply. We will refactor accordingly.