CODEWITHSUNDEEP
linuxmultithreadingpthreads
Daniel
Daniel

Reputation: 289

linux multithread scheduling

I have a program launching about 12 threads on 8-core server. some of the threads are waiting for critical data. where it's using a recv in loop, the recv will block until data comes. However when there is data, it needs to process it asap.

one thing I noticed is that from time to from when the connection is quiet, the thread doesn't have much activity. the thread maybe put to sleep (suspect?), then when data comes in, it needs to wake up first, therefore wasting time. I'm wondering if there is anyway to set so the thread will not be put to sleep and wake up later? thanks!

Upvotes: 4

Views: 643

Answers (2)

Scott Lamb
Scott Lamb

Reputation: 2216

As Martin James said, blocking is a normal thing to do, whether through a simple recv or through epoll in an event-driven server. If you haven't observed a real measurable latency problem, I wouldn't worry about it. You're doing what everyone does.

And by real measurable latency problem, I mean a difference between your well-defined goal (say, 50% latency of 1 ms, 99.9%ile latency of 100 ms measured at the client under a certain load pattern, maybe bursty if you're concerned about blocking) and reality.

That said, I have heard of very latency-focused people complaining about the kernel putting the processor in too deep of a sleep state when there's not enough work to keep processors busy, causing too much latency on wake-up. I think this would be something you'd want to control at the kernel level, not your application. I don't see off-hand any numbers on the latency, so again this is something you'd want to measure: find (or create) a way to control the deepest sleep state it uses and measure the effect.

Upvotes: 2

Arno
Arno

Reputation: 5194

It's not just your threads, there are other threads too. Within a large range it does not matter how many thread you actually have. Other threads are likely to get choosen by the scheduler while your thread is waiting on the recv. So when there is data to let your recv return your thread will get ready to run and may be choosen by the scheduler for execution. If all cores are occupied by threads of equal of higher priority than your thread and if their time slice not just luckely ends, your thread would have to wait for the cpu. However, in order to get your thread scheduled immedeately after the recv has data, you should raise your threads priority. In this case the recv return will make your thread "runnable" and the scheduler will swtich to it before it considers any other threads of lower priority. If neccessary it will even stop a thread of lower prioriy of your thread.

Upvotes: 2

Related Questions