Looks like the fallback if gethrtime doesn't exist is a bit arbitrary:
static void check_threads(struct callback *cb, void *arg, void * arg2) { #ifdef HAVE_GETHRTIME static long long last_; if( gethrtime()-last_ < 50000000 ) /* 0.05s slice */ return; last_ = gethrtime(); #else static int div_; if(div_++ & 255) return; #endif
This only works if check_threads is called at approximately even time intervals, which probably isn't true at all.
I'd like to add a fallback to clock():
#elif defined(USE_CLOCK_FOR_SLICES) if (clock() - thread_start_clock < (clock_t) (CLOCKS_PER_SEC / 20)) return; #else
where thread_start_clock is set to clock() in SWAP_IN_THREADS (since clock() measures the thread local cpu time).
Thoughts? I know that clock() has bad precision, but I think it should be adequate down to the 1/20 sec resolution used here.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-09-05 16:06: Subject: Frequent context switches
I've become aware of an issue where a multithreaded pike application on Linux causes very frequent context switches (around 17000 per second). It's about five threads that all do a lot of data structure manipulation in pike code.
What could be the cause of this? Is th_yield called way too often? Or is it possible that the thread lib is so stupid that it schedules all threads that hangs on the interpreter lock in round-robin fashion?
/ Martin Stjernholm, Roxen IS