On Sun, 2004-10-24 at 19:06, Ingo Molnar wrote:

i think i fixed this in my PREEMPT_REALTIME tree (having seen spinning
eh_threads) - maybe Thomas forgot to merge those fixes back?

(in a PREEMPT_REALTIME kernel a spinning thread is just a thread eating
up CPU power, it doesnt cause a hang.)

I've really got to say, I don't like what you're doing.  This program
seems to replace

if (condition)
	up(sem);
[...]
down(sem);


with

if (condition)
	up(event_queue);
[...]
wait_event(event_queue, condition);

That can be wrong on three counts:

1) The condition is a local one that will fluctuate between the wake_up
and the actual thread being scheduled to run
2) The actual condition you need to check for might not be the same as
the one that triggered the wake_up.  This is what the SCSI problem was.
3) There might genuinely be n triggers of the event.  With a semaphore,
if we get three up()'s before the waiting thread is schedules, it will
process three times.  With wait_event, the other two will be lost.

Thus, to effect this replacement, you need a thorough audit of what is
usually pretty non-trivial code.

What's the overriding reason for doing this?  the pain doesn't look to
be worth the gain (since I don't see any gain).

James