Hi,
I have a project where it reads "a lot" of data from a USB device. The reading is done by a helper DLL that uses an STL deque as temp buffering, in that way I can create optimized code within the DLL to read from the USB device at maximum speed and the user app. can read at any speed.
So, if the push/popping of the deque were to run into any kind of memory problems I assume I will be getting an exception by windows' structured exception system and not the VCL, correct?
If I got a memory problem I could halt the reading, wait for the deque to be read and then continue or simply quit and report the error. Can I catch the exception and "hide it" or will it reach the user anyway?
Your potentially problem may come from latency instead of "bandwidth". I mean that if you receive
a burst of close data, you may lose some because the reallocation or creation of new space in the
data structure may cause an overrun in the driver or device buffer.
You can use a circular buffer (but you have to synchronize it if producer and consumer(s) are
different threads) or you can use two fixed buffers (large enough to fit your needs) alternating them
in this fashion: the producer (the thread connected to the usb device) produces data only in a selected
buffer; you do not even need to synchronize the writes because the producing thread is alone when
it writes on the selected buffer (no readers, no other writers). When the buffer is full, you simply swap
the two buffers (in a synchronized operation, using a std::mutex o a TCriticalSection). The swap operation
is very fast, so to mitigate the latency problem, i.e. the thread connected to the usb (the producer)
has readly space in order to store new incoming data. Now you can read the data from the swapped
buffer using a std::conditional_variable + std::mutex if you have more than one consumer thread
(remeber that semaphores are not suitable if you have more than one consumer thread). The only
evident drawback from this approach is the delay introduced by the buffer(s) lenght (you have to fill
buffers or to wait for an arbitrary lenght timeout in order to see data coming from the peripheral).
But if you can live with it...
Note that a similar approach is normally taken in hardware's drivers for audio or data acquisition
peripherals (but, of course, usually are involved even interrupts).
Regards
Connect with Us