Context Switching delay in centos7

Question

In my C application, the main process forks a child process and then sleeps for ten microseconds to give the child time to get ready. After the sleep period, the parent process sends a signal to the child process to start listening on the specified port.

This code executed fine in CentOS6, and there were only few instances where the sleep period was not enough for the child process to setup its signal handlers before the signal from the parent was delivered. When this code was run in CentOS7 with the same system specifications, however, the child consistently failed to install its signal handlers in time. I had to increase the sleep period to 10 milliseconds (1000 times longer) to get the same performance as I was getting in CentOS6.

I would like to know what might be reasons for context switching to be so slow in CentOS 7 relative to CentOS 6 on same-spec hardware?

Answer 1

Differently compiled kernels behave differently. You can't rely on time intervals for such things. Since you have signal handler installed in parent why not just reverse the logic: When the child is ready it can send signal to the parent and then the parent can start to control the child - nobody is busy sleeping and everything is event driven

Answer 2

Process / thread scheduling is at the discretion of the OS kernel. CentOS 7 uses a different kernel than does CentOS 6.

In any event, this is not necessarily a context-switching problem at all. Context switching applies to threads / processes sharing the same CPU [core], but single-core CPUs are rare these days, at least on the classes of machines where you would expect to find CentOS. The matter could in fact be whether the child is initially scheduled on the same core as the parent, and if so, which returns first from fork().

Suppose, for example, that that on CentOS 6, child and parent normally ended up scheduled (initially) on the same core, with the child getting that core first. In that case, the parent doesn't really need to delay at all as long as the child gets its signal handlers set up before it first yields the CPU. If on CentOS 7, on the other hand, the child typically gets initially scheduled on a different core, and both processes proceed right away, then the delay that didn't actually matter before suddenly does matter. That would be a performance improvement by most measures, by the way.

All of that is speculative, of course. The main problem is that your approach is deeply flawed. The parent should not try to guess when the child will be ready. Instead, it should wait for the child to announce its readiness. The child might do so via a pipe or by signaling the parent, or perhaps better, they could synchronize via a shared semaphore or mutex (which is after all what those objects are for).