Boost logo

Boost :

From: Jupiter (jupiter.hce_at_[hidden])
Date: 2020-09-10 00:57:49


Thanks Richard and Gavin.

You right, I'll limit the one thread write inside of class, never
calling the write outside of class. the single thread wasted too much
resources where it is running an intensive MOSI and MISO UART process.

I think it is a design issue, if I can design different threads to run
different IO spaces, a simple boost::thread should do the job nicely.

Thank you very much.

jupiter

On 9/8/20, Gavin Lambert via Boost <boost_at_[hidden]> wrote:
> On 7/09/2020 22:12, Richard Hodges wrote:
>> If your implementation is single threaded, you don't need to worry about
>> concurrency issues at all. All completion handlers will be scheduled to
>> run
>> sequentially.
>
> That's almost true. The one other place you need to be careful of is
> when initiating operations externally (usually writes, since reads are
> typically only initiated from completion handlers, but writes can come
> from both inside and outside).
>
> The best thing to do there is to not try to directly issue writes from
> "outside", but instead post() the request to start the write to the same
> io_context that's managing the socket.
>
> (The fundamental write operation itself doesn't really care which thread
> you start it from, but usually you'll want to manage other state
> variables in the class when initiating writes, and those can be
> protected by ensuring you only touch them from the io_context thread.)
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

--
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk