What is the advantage of strand in boost asio?

Question

Studying boost asio and find out a class called "strand", as far as I understand. If there are only one io_service associated to a specific strand and post the handle by the strand.

example(from here)

boost::shared_ptr< boost::asio::io_service > io_service(      new boost::asio::io_service ); boost::shared_ptr< boost::asio::io_service::work > work(     new boost::asio::io_service::work( *io_service ) ); boost::asio::io_service::strand strand( *io_service );  boost::thread_group worker_threads; for( int x = 0; x < 2; ++x ) {     worker_threads.create_thread( boost::bind( &WorkerThread, io_service ) ); }  boost::this_thread::sleep( boost::posix_time::milliseconds( 1000 ) );  strand.post( boost::bind( &PrintNum, 1 ) ); strand.post( boost::bind( &PrintNum, 2 ) ); strand.post( boost::bind( &PrintNum, 3 ) ); strand.post( boost::bind( &PrintNum, 4 ) ); strand.post( boost::bind( &PrintNum, 5 ) ); 

Then the strand will serialized handler execution for us.But what is the benefits of doing this?Why don't we just create a single thread(ex : make x = 1 in the for loop) if we want the tasks become serialized?

Answer 1

Think of a system where a single io_service manages sockets for hundreds of network connections. To be able to parallelize workload, the system maintains a pool of worker threads that call io_service::run.

Now most of the operations in such a system can just run in parallel. But some will have to be serialized. For example, you probably would not want multiple write operations on the same socket to happen concurrently. You would then use one strand per socket to synchronize writes: Writes on distinct sockets can still happen at the same time, while writes to same sockets will be serialized. The worker threads do not have to care about synchronization or different sockets, they just grab whatever io_service::run hands them.

One might ask: Why can't we just use mutex instead for synchronization? The advantage of strand is that a worker thread will not get scheduled in the first place if the strand is already being worked on. With a mutex, the worker thread would get the callback and then would block on the lock attempt, preventing the thread from doing any useful work until the mutex becomes available.