Thanks Richard for bringing this to our attention and testing it. Here is the code I used, in case any other multi-threading application needs to do the same:
#ifdef MSVC #define getThreadPriority() GetThreadPriority(GetCurrentThread()) #define setThreadPriority(num) SetThreadPriority(GetCurrentThread(), num) #else #include <sys/resource.h> #define getThreadPriority() getpriority(PRIO_PROCESS, 0) #define setThreadPriority(num) nice(num) #endif getThreadPriority() is called before forking (by OpenMP in AQUA's case), and setThreadPriority() is then called by each worker thread. MSVC is defined for compiling under Windows and is undefined for Linux and Mac. -Kamran -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Richard Haselgrove Sent: Friday, December 18, 2009 2:19 AM To: David Anderson Cc: BOINC Developers Mailing List Subject: Re: [boinc_dev] CPU thread priority for multi-threaded apps The AQUA devs have had a second go at fixing the problem, and this time they've cracked it: http://img268.imageshack.us/img268/4364/aquathreadsfixed.png They say "[This] one notes the priority of the main thread (set by BOINC) before other threads are started, and then each new thread sets its priority to be the same as this value." Other developers of MT applications please copy: congratulations and thanks to the AQUA devs for being so responsive. > Hopefully that will fix the problem; > I'd like to avoid dealing with variable # of threads. > -- David > > Richard Haselgrove wrote: > ... >> >> Originally, the AQUA devs hadn't noticed any issues: it was my experience >> of the slow-down of Jason's hybrid CUDA app that prompted the enquiry. >> But now that they're looking at it more closely, it may explain why the >> multiple application threads tend to finish at different times: the >> single thread with priority 1 will be interrupted for Windows (and >> BOINC/CUDA) housekeeping far more often than the threads with priority 4. >> This means that AQUA tasks tend to finish with three cores idle for the >> last few minutes, and the poor old 'priority 1' thread panting across the >> line a distant last. >> >> At the moment, the BOINC client scheduler can't make use of those idle >> resources: all cores are released back to BOINC 'en bloc' when the whole >> task finishes. Releasing individual cores for re-use by BOINC is probably >> a scheduler request too far, but if thread equality levels the playing >> field, efficiency overall should improve - the AQUA devs are looking into >> it. >> > > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
