On Wed, Aug 26, 2009 at 11:16 AM, Michael Caisse < boost@objectmodelingdesigns.com> wrote:
Robert Dailey wrote:
Would you recommend calling read_start() from its own thread and have it loop indefinitely? I believe this is what you originally suggested. However, I am curious about the issues with calling read_some() and write_some() from separate threads without using any external synchronization techniques (i.e. mutexes). Do I have to synchronize these two calls manually or is it done internally? I'll re-review the documentation, but I did not see anything regarding this earlier.
Thanks for your help.
The io_service takes care of the "threading" issues for you. Just call read_start once from (lets say) main to get the processes going and then it all happens in the background... asynchronously. The call to read_start doesn't block. If you want different threads to operate on the io (though I recommend not doing this at first) then you can use a thread pool to call the io_service.run method from multiple threads.
Have a look at some of the examples to see how it is all put together. Reading/writing to serial ports is the same as reading/writing to sockets using asio. I like to recommend the chat server/client example. It pulls together a lot of asio concepts in an easy to understand application.
Thanks, I'll have a look at that. I understand what you are saying. I actually figured that out shortly after I posted. So I'm calling read_start() at the beginning and letting it take over, however I have one concern. I have a thread that loops, continuously calling io_service::run(). Will run() block while waiting for data to read? If so, this could potentially block any writes that occur after it. For example, suppose I do an async_read_some(), and then shortly after that I call boost::asio::async_write(). Will the write be blocked by the read? I'm probably going to be sending a lot more data than receiving it, and if this is the case it would really deadlock my application. Thanks again for all of the great support.