Question

Since the strand will not be executed concurrently, what is the difference in performance between strand and single thread? Moreover, a lock is not necessary to protect the share data in the handler of post function, right?

suppose an application performance several jobs, below is some sample code.

strand.post(boost::bind(&onJob, this, job1));

void onJob(tJobType oType)
{
  if (oType == job1)
   // do something
  else if(oType == job2)
   // do something
}

Edit: I try to measure the latency from post and calling onJob is quite high. I would like to know if there is any way to reduce it

Answer 1

A strand will typically perform better than a single thread. This is because a strand gives the scheduler and the program logic more flexibility. However, the differences are typically not significant (except in the special case I discuss below).

For example, consider the case where something happens that requires service. With a strand, there can be more than one thread that could perform the service, and whichever of those threads gets scheduled first will do the job. With a thread, that very thread must get scheduled for the job to start.

Suppose, for example, a timer fires that creates some new work to be done by the strand. If the timer thread then calls into the strand’s dispatch routine, the timer thread can do the work with no context switch. If you had a dedicated thread rather than a strand, then the timer thread could not do the work, and a context switch would be needed before the work created by the timer routine could even begin.

Note that if you just have one thread that executes the strand, you don’t get these benefits. (But, IMO, that’s a dumb way to do things if you care about performance at this fine a level.)

For some applications, carefully breaking your program into strands can significantly reduce the amount of lock operations required. Objects that are only accessed in a single strand need not be locked. But you can still get a lot of the advantages of multi-threading. (One big disadvantage though — if any of your code ever blocks, it will stall the entire strand. So you either have to not mind if a strand stalls or make sure none of your code for a critical strand ever blocks.)

In this case, you can have three strands, A, B, and C, and a single thread can do some work for strand A, some for strand B, and some for strand C with no context switches (and with the data hot in the cache). Using a thread for each task would require two context switches to do the same job, and each task would likely not find the data in cache. If you constantly “hand things” from strand to strand, strands can significantly outperform dedicated threads.

As to your second question, a lock is not needed unless data is being accessed in one thread while it could possibly be being modified in another thread. If all accesses to an object are through a single strand, locks are not needed because a strand can only execute in one thread at a time. Typically, strands will access some data that is only accessed by that strand and some that is shared with other threads or strands.