Embarcadero Discussion Forums: Windows Memory management ...

Welcome, Guest: Login; Guest Settings

Thread: Windows Memory management

This question is answered. Helpful answers available: 2. Correct answers available: 1.

Reply to this Thread

Search Forum

Back to Thread List

	Replies: 5 - Last Post: Apr 13, 2018 2:01 AM Last Post By: Goran Ekstrom

Goran Ekstrom

Posts: 149
Registered: 1/10/04

Windows Memory management

Posted: Apr 12, 2018 11:22 AM

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?

Regards
Goran

Remy Lebeau (Te...

Posts: 9,447
Registered: 12/23/01

Re: Windows Memory management [Edit]

Posted: Apr 12, 2018 11:43 AM

in response to: Goran Ekstrom

Goran Ekstrom wrote:

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?

Maybe. C++Builder likes to route the 'new'/'delete' operators through
the same memory manager that the Delphi RTL uses, so you may get a
VCL exception, or you may get a C++ excepton from the STL. It
depends on the nature of the exception.

But yes, on Windows, most types of exceptions, VCL included, ultimately
use SEH under the hood.

Also, note that there are 3rd party solutions for converting SEH
exceptions into VCL exceptions.

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.

Don't rely on memory errors to handle things like that. Keep track of
your queue status and simply don't read from it when it has nothing to
read. std::deque has an empty() method, for instance. Or use a
std::conditional_variable or Syncobjs::TEvent or other sync object of
your chosing to signal your code when the std::deque has data available
and when it is empty.

Can I catch the exception and "hide it" or will it reach the user
anyway?

If you catch it, then of couse the user will not see it.

--
Remy Lebeau (TeamB)

Alex Belo

Posts: 626
Registered: 10/8/06

Re: Windows Memory management [Edit]

Posted: Apr 12, 2018 9:10 PM

in response to: Goran Ekstrom

Goran Ekstrom wrote:

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.

"Any speed" with deque push/pop? It can work only for quite low speed
of data acquisition (up to 10K samples per second or so, I believe).

if the push/popping of the deque were to run into any kind of
memory problems

If you use different threads for acquisition (push) and processing
(pop) don't forget to create some synchronization: simultaneous access
from both sides will crash your application.

--
Alex

Martin van der ...

Posts: 57
Registered: 7/14/02

Re: Windows Memory management

Posted: Apr 13, 2018 12:53 AM

in response to: Goran Ekstrom

My experience with memory errors is that the application will just crash rather than throw an exception, so don't rely on that. The throwing part simply didn't work last time I ran into this. You'll have to watch your memory usage.

Arkady Semylio

Posts: 9
Registered: 5/25/17

Re: Windows Memory management

Posted: Apr 13, 2018 1:08 AM

in response to: Goran Ekstrom

Goran Ekstrom wrote:
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

Goran Ekstrom

Posts: 149
Registered: 1/10/04

Re: Windows Memory management

Posted: Apr 13, 2018 2:01 AM

in response to: Goran Ekstrom

Thanks all.

I've opted to skip the deque and will go for a fixed size circular buffer instead. In that way the memory management is more predictable and the interthread bandwidth is high.

Back to Thread List

Legend
	Helpful Answer (5 pts)
	Correct Answer (10 pts)

Developer Tools

Database Tools