device driver memory buffer processor cache issue

Question

I have a device which sends image data and video frame using two different bulk channels in USB.

My workstation processor cache is little bit large enough to hold around 100 video frames without any issue but not image data.

I'm using same buffer for image and video data and that buffer have around 50 blocks and one block is 1MB size. The video frames come quickly and then the image frame.

My question is, is there is a memory corruption issue in the following secnario ? Somebody who have knowledge in processor cache could help me.

• Because of video frames are small the pages in the memory buffer which writes video frames are almost in the cache. Since video data comes as a stream it never flushed out.
• but when the image data comes, the large area of the memory buffer will be used, then video memory pages will be flushed out. But scheduled to be flushed but still not written to the physical memory.
• Now image data was written to the memory, I've used volatile there.
• And that data will be corrupted by the cache flush when they were flushed after the image data write.

Can this happen? So I applied volatile to video data write too and this issue looks like it disappeared. But I need to make a report, so is it possible for this above mentioned scenario to happen?

Answer 1

The comments are the giveaway: two threads, and volatile is misused as a threading mechanism.

Two threads can run on two CPU cores. While the cores usually do share memory, they usually do not share the L1 cache. Intermediate caches vary. As a result, dereferencing the same pointer on two CPU cores may give different results. This is not a problem for variables that are properly shared across threads; the compiler will use the correct instructions. But the keyword is properly shared.

Here we get into the slight problem that you've tagged your question both as C and C++, because the two languages forked before threading was standardized in either language. However, the two threading mechanisms are intentionally similar so that a compiler pair can (as an extension) define how C threading and C++ threading interact. You'll need to consult your documentation for that.

It may be easier to wrap the libusb thread in your own code, so that you receive the data without threading issues, and then dispatch from your code to other threads that are also under your control.

Back to the memory corruption you're seeing: what you probably see is that one thread is writing out its view of memory, which turns out to be stale data in its cache. Had you used something like a mutex, this stale data would have been noted and caches synchronized.