On 31 Mar 2004 11:39:36 -0600, Jack O'Quin <joq(a)io.com> wrote:
Arve Knudsen <aknuds-1(a)broadpark.no> writes:
True .. That was one approach I considered
originally while sketching
up solutions, I guess it slipped my mind in the meantime :| I was
thinking it could possibly be an expensive operation though as NPTL
sources seem to indicate, maybe best avoided if memory locks are
involved (I'm no optimization guru, I'm sure you can tell).
It doesn't look all that expensive. The magic is done by a platform-
dependent compare-and-swap operation. On some SMP machines that can
be slow, but generally only in high-contention situations (AFAIK).
According to the
comments it could involve a memory lock though, wouldnt
this be expensive either way?
Anyway, do you
think it would be good to keep a canary around to act
on CPU starvation?
Personally, I don't see much need for a canary thread. Others may
disagree. But, a watchdog is quite helpful for debugging. In some
cases, the application will provide its own watchdog. Is it possible
for that thread to be optional?
I can see why people might want a canary (a FIFO
process eating all CPU
leads to a not so responsive system :/), but it would almost certainly be
the client code hogging CPU. Maybe we could introduce a compile time
conditional, and/or an environment variable (default would be on)? Perhaps
the canary could be conditional as well.
Regards
Arve Knudsen