0

Trying to implement a produced consumer scenario where one process feeds cv::Mat objects into a queue buffer. And the consumer consumes them. cv::Mat has a settable allocator that can be implemented for custom memory management, but I had no success in making it work. Popping from the que on consumer side led to segfaults. The closest I've got is this implementation whwre cv::Mat is serialized and deserialized. Another downside of this implementation is buffer size is defined during compilation. So to reiterate the questions: how to efficiently implement cv::Mat lockfree queue in a shared memory.

Related questions:

alex
  • 425
  • 4
  • 21
  • I think the [linked implementation](https://gist.github.com/aleksas/64521cec1b5fa05477a47f46ad62f8b5) looks solid. Also, consider very critically whether you need lcckfree::queue vs lockfree::spsc_queue. It's very easy to shoot yourself in the foot due to additional restrictions on the thread use w.r.t. spsc_queue – sehe Nov 18 '20 at 20:25

1 Answers1

0

The "settable" allocator for cv::Mat is NOT a Boost Interprocess allocator.

It looks like it's gonna be "hard" to implement the cv::Matallocator interface to wrap one, as well.

This could be because the fancier allocators are intended for CUDA support, but I'm guessing a bit here.

So, I'd strongly suggest serializing. This should be okay unless you're dealing with giant matrices. See e.g.

Of course you can serialize to shared memory: https://www.boost.org/doc/libs/1_37_0/doc/html/interprocess/streams.html or https://www.boost.org/doc/libs/1_74_0/libs/iostreams/doc/quick_reference.html#devices

Now if you need large matrices (and they NEED to be OpenCV anyways) consider using existing CV allocators to allocate from an already existing contiguous buffer in your shared memory.

This could be as simple as just a vector<int8_t, bip::allocator<int8_t> > or, indeed array<int8_t, 4096> constructed inside shared memory (either managed (managed_shared_memory) or unmanaged (bip::mapped_region that works on top of bip::shared_memory_object).

sehe
  • 374,641
  • 47
  • 450
  • 633
  • Thanks. My attepmt to implement as you've suggested: [coliru](http://coliru.stacked-crooked.com/a/f88180893581729b). For starters simple strings instead of cv::Mat. Changed to lockfree::queue and vectors instead of base_string. Does not compile yet though. :) – alex Nov 18 '20 at 22:35
  • @alex I hadn't used `lockfree::queue` before, but looking at the requirements shows it requires trivial assignment and destructor: https://www.boost.org/doc/libs/1_54_0/doc/html/boost/lockfree/queue.html. Vectors don't have that. – sehe Nov 18 '20 at 23:51
  • Next step: [this](http://coliru.stacked-crooked.com/) uncovers that `lockfree::queue` doesn't support [allocators with fancy pointers](https://quuxplusone.github.io/draft/fancy-pointers.html). That just rules out BIP allocators, completely. (Oh by the way, I use [camomilla](https://www.youtube.com/watch?v=3dUZn3eloWE) to parse [those errors](https://paste.ubuntu.com/p/hCdjZGfxb4/)) – sehe Nov 19 '20 at 00:24
  • The docs state [otehrwise](https://www.boost.org/doc/libs/1_66_0/doc/html/lockfree.html#lockfree.introduction___motivation.data_structure_configuration). However, I can only make that tick for compile-time capacity (which is meh because it really doesn't want to allocate anyways). Here's what I got: http://coliru.stacked-crooked.com/a/eebc45fb1f5c48cc – sehe Nov 19 '20 at 00:53
  • Hmm, not just queue size but also vec size now is fixed at compile-time :( . Without that extra capacity restriction queue would be an ease choice over spsc_queue. – alex Nov 19 '20 at 11:59