while<\/code> loop is difficult to get wrong. For example:<\/p>\n\r\n\/* iterate through users *\/\r\ncounter = 0;\r\nwhile ( counter < numusers ) {\r\n printf( "User %s\\n", user[counter] );\r\n counter++;\r\n}\r\n<\/pre>\nThis code will always complete because counter<\/code> will always reach numusers<\/code> eventually and cause the loop to end.<\/p>\nThe counter<\/code> variable is the<\/i> “condition variable” for this loop because the while<\/code> loop has a condition dependent on the counter<\/code> variable. And this loop does, indeed, update the condition variable every iteration (by the counter++;<\/code> statement).<\/p>\nThe problem lies in larger organisations when multiple people are making changes to source code – perhaps when making a fix in response to a bug report. They may add some code like this:<\/p>\n
\r\n\/* iterate through users *\/\r\ncounter = 0;\r\nwhile ( counter < numusers ) {\r\n \/* bug report 14132 - ignore user "secretuser" *\/\r\n if ( strcmp( user[counter], "secretuser" ) == 0 ) {\r\n \/* match! loop again to avoid printing secretuser *\/\r\n continue;\r\n }\r\n\r\n printf( "User %s\\n", user[counter] );\r\n counter++;\r\n}\r\n<\/pre>\nNow we have a problem. If \"secretuser\"<\/code> appears in the user[]<\/code> array then counter<\/code> will no longer be incremented and the while loop will continue forever.<\/p>\nA for<\/code> wouldn’t have this issue. Imagine if the loop had started out as:<\/p>\n\r\n\/* iterate through users *\/\r\nfor ( counter = 0; counter < numusers; counter++ ) {\r\n printf( "User %s\\n", user[counter] );\r\n}\r\n<\/pre>\nand then the maintainer added the bug fix:<\/p>\n
\r\n\/* iterate through users *\/\r\nfor ( counter = 0; counter < numusers; counter++ ) {\r\n \/* bug report 14132 - ignore user "secretuser" *\/\r\n if ( strcmp( user[counter], "secretuser" ) == 0 ) {\r\n \/* match! loop again to avoid printing secretuser *\/\r\n continue;\r\n }\r\n\r\n printf( "User %s\\n", user[counter] );\r\n}\r\n<\/pre>\nThe fact that counter<\/code> was incremented in the for<\/code> loop declaration ensures this loop will complete even though the maintainer added a continue<\/code> statement inside the loop.<\/p>\nThus for<\/code> loops offer greater protection against accidental infinite looping.<\/p>\nA tight while loop is bad<\/h3>\n
If a CPU finds itself in the situation where it is in a tight while loop things can be worse than one might ordinarily expect. That’s because it might never find itself calling an operating system function – which would give the operating system a chance to consider whether anything else needs to be done (outside the application) – before returning control to the program.<\/p>\n
Instead the CPU is executing instructions furiously over and over again – until a scheduled timer interrupt forces the CPU to visit the operating system and something else is given a chance to run.<\/p>\n
So things are not utterly dire – other code does get a chance to run on the processor. But it’s not well behaved and polite like most programs are. Still, this kind of impolite hogging of the CPU does have consequences and is worth being aware of.<\/p>\n
Back to the story<\/h3>\n
My suspicion was confirmed whereupon I found a while<\/code> loop that had a rogue continue<\/code> statement without any accompanying code to update the condition variable.<\/p>\nQuite simply I started grepping for the string continue<\/code> and closely reviewed any while<\/code> loop that contained the keyword. And that is how I found the fault.<\/p>\nIndeed it had been a bug fix. And was only triggered occasionally because it added an exception to the normal operation. In testing this exception had not been encountered.<\/p>\n
But in production the exception was being triggered on occasion by real customers – and when it did their web session froze (never responded) and the process locked up at 100% CPU utilisation each time.<\/p>\n
It was fortunate this issue was identified, and fixed, before whole servers became overwhelmed with CPU load.<\/p>\n","protected":false},"excerpt":{"rendered":"
It was a curious thing. A website had been deployed to powerful production servers. These servers had many CPU cores. Yet every morning the system administrators would notice several processes using 100% cpu utilisation. At first it was just one or two rogue web application processes which could be easily killed off. But as the … <\/p>\n
Continue reading “The case of CPUs becoming 100% busy”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22],"tags":[],"class_list":["post-215","post","type-post","status-publish","format-standard","hentry","category-technical"],"_links":{"self":[{"href":"https:\/\/www.itfault.com.au\/main\/wp-json\/wp\/v2\/posts\/215","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.itfault.com.au\/main\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.itfault.com.au\/main\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.itfault.com.au\/main\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.itfault.com.au\/main\/wp-json\/wp\/v2\/comments?post=215"}],"version-history":[{"count":15,"href":"https:\/\/www.itfault.com.au\/main\/wp-json\/wp\/v2\/posts\/215\/revisions"}],"predecessor-version":[{"id":334,"href":"https:\/\/www.itfault.com.au\/main\/wp-json\/wp\/v2\/posts\/215\/revisions\/334"}],"wp:attachment":[{"href":"https:\/\/www.itfault.com.au\/main\/wp-json\/wp\/v2\/media?parent=215"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.itfault.com.au\/main\/wp-json\/wp\/v2\/categories?post=215"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.itfault.com.au\/main\/wp-json\/wp\/v2\/tags?post=215"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Three](\"https:\/\/www.itfault.com.au\/main\/wp-content\/uploads\/2017\/08\/2017-08-31-htop-3-cpu-cores-busy.png\")