0

I'm in the design phase of a program that will have 10-30 threads, where each thread will process many small blocks of information.

I have the option of each block sleeping for 5 ms or not sleeping at all. I should choose whichever reduces load on the CPU.

Normally I would sleep to reduce CPU utilization, but I am concerned that many 5 ms sleeps may, because of context switching, cause CPU utilization to increase rather than decrease.

Are there any studies already done on the trade off between short sleeps and context switching on CPU utilization?

Lurk21
  • 2,307
  • 12
  • 37
  • 55
  • It depends on your CPU of course, and the number of them, and your operating system, but are these threads really going to do nothing except compute? No I/O for example? If they're going to execute system calls I would omit the sleeps altogether and let them just go full speeed ahead. The operating system will cope. You could consider lowering their *priority.* – user207421 Nov 27 '14 at 04:33
  • EJP, There will be no I/O in the portion of the system I've described - it will be pure compute. I'll consider lowering their priority. – Lurk21 Nov 27 '14 at 04:52
  • 1
    If a computer running at 1GHz can run one operation per clock cycle, that's 5 million operations in 5ms. You can do a *lot* of context switches in that amount of time! – Gabe Nov 27 '14 at 07:10
  • Keep in mind that a Sleep(1) may wait the same time as a Sleep(10), depending on timer resolution. – Alexander Gessler Nov 27 '14 at 16:59
  • Assuming you have a fixed amount of work to do, sleeping means that you will occupy the CPU for longer and be unable to take advantage of periods where the system has no other work to do. This is just a *bad* idea and you should reject it. – David Schwartz Dec 08 '16 at 07:33

2 Answers2

2

Sleeping is an option of last resort. Instead, have a look at the tool in the concurrent API, especially the Queues which allow you to put a task to sleep until a message arrives on which it should act.

Or look at Akka which allows you to easily build a system where a few threads process thousands of messages. The main drawback here is that you have to design your system around Akka - it's really not something that you can easily retrofit.

If speed is your main concern, look at blocking free algorithms like this one "Single Producer/Consumer lock free Queue step by step" or LMAX Disruptor.

Related:

Community
  • 1
  • 1
Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
0

I tested it. Anecdotally, I started to see a benefit at a 3 ms sleep, increasing dramatically with each additional ms after that.

The test was done with 30 threads running on an Intel Core i3-4130. Each thread created an array list of 1000 Strings, each String is randomly generated with commons lang and is 1000 characters long.

The thread then alternated between shuffling and sorting the list.

Disclaimer: this is a short set of tests on one desktop cpu - not a study.

Lurk21
  • 2,307
  • 12
  • 37
  • 55