Date: Wed, 18 Jan 2023 15:42:14 +0000
Hi Scott,
Thank you for your reply.
Yes
, it's a multithreaded program. I believe multiprocess constructs could be
used along side threads as well. I've tried benchmarking using std::queue
protected with a std:: unique_lock & condition_var for the same scenario.
But performance results was not that great. Let me know what you think.
Best,
Honey
On Wed 18 Jan 2023, 8:01 a.m. Scott Michaud, <scott_at_[hidden]> wrote:
> You say that you have a producer-consumer scenario with multiple *threads*.
> Are they all in the same executable / process?
>
> On Tue, Jan 17, 2023 at 10:52 PM Honey Sukesan via SG14 <
> sg14_at_[hidden]> wrote:
>
>> Hi all,
>>
>> Hope all is well.
>>
>> This is my first email to the list. Not sure if it's the place to ask
>> general technical questions. Please accept my apologies if I'm violating
>> any rules of this study group.
>>
>> I would like to seek an opinion regarding boost:: interprocess::
>> message_queue vs boost::lockfree::queue.
>>
>> Has anyone used boost::lockfree::queue or any of Boost.LockFree data
>> structures in any embedded platforms?
>>
>> I have a producer-consumer scenario involving multiple threads. Tried out
>> a sample code using int values pushing to/consuming from the queue &
>> analysed elapsed time between push/pop on a Linux x86. It's found
>> boost::lockfree::queue gives better time performance results compared to
>> boost:: interprocess:: message_queue.
>>
>> Haven't tried this on actual hardware target yet. Our hardware target is
>> an ARM based processor running QNX RTOS.
>>
>> I'm listening to Herb's CppCon talk on Lock-free programming now.
>>
>> It would be great if any of you has any other recommendations/pros or
>> cons I need to be aware of before I fix boost::lockfree::queue rather than
>> boost:: interprocess:: message_queue in our production code?
>>
>> Thank you in advance,
>> Best,
>> Honey
>>
>> Honey Sukesan
>>
>>
>>
>>
>> _______________________________________________
>> SG14 mailing list
>> SG14_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>>
>
Thank you for your reply.
Yes
, it's a multithreaded program. I believe multiprocess constructs could be
used along side threads as well. I've tried benchmarking using std::queue
protected with a std:: unique_lock & condition_var for the same scenario.
But performance results was not that great. Let me know what you think.
Best,
Honey
On Wed 18 Jan 2023, 8:01 a.m. Scott Michaud, <scott_at_[hidden]> wrote:
> You say that you have a producer-consumer scenario with multiple *threads*.
> Are they all in the same executable / process?
>
> On Tue, Jan 17, 2023 at 10:52 PM Honey Sukesan via SG14 <
> sg14_at_[hidden]> wrote:
>
>> Hi all,
>>
>> Hope all is well.
>>
>> This is my first email to the list. Not sure if it's the place to ask
>> general technical questions. Please accept my apologies if I'm violating
>> any rules of this study group.
>>
>> I would like to seek an opinion regarding boost:: interprocess::
>> message_queue vs boost::lockfree::queue.
>>
>> Has anyone used boost::lockfree::queue or any of Boost.LockFree data
>> structures in any embedded platforms?
>>
>> I have a producer-consumer scenario involving multiple threads. Tried out
>> a sample code using int values pushing to/consuming from the queue &
>> analysed elapsed time between push/pop on a Linux x86. It's found
>> boost::lockfree::queue gives better time performance results compared to
>> boost:: interprocess:: message_queue.
>>
>> Haven't tried this on actual hardware target yet. Our hardware target is
>> an ARM based processor running QNX RTOS.
>>
>> I'm listening to Herb's CppCon talk on Lock-free programming now.
>>
>> It would be great if any of you has any other recommendations/pros or
>> cons I need to be aware of before I fix boost::lockfree::queue rather than
>> boost:: interprocess:: message_queue in our production code?
>>
>> Thank you in advance,
>> Best,
>> Honey
>>
>> Honey Sukesan
>>
>>
>>
>>
>> _______________________________________________
>> SG14 mailing list
>> SG14_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>>
>
Received on 2023-01-18 15:42:25