Re: Signals and preemption-related question

On 2009-08-22 at 01:54:20 [+0200], Rene Gollent
<anevilyak@...> wrote:
> 
> Michael and I were having a discussion about the current behavior with
> respect to preemption on release_sem_etc and/or signal delivery, and
> an uncertain question crops up: In quite a few cases, if a thread is
> woken up by either one, that wakeup is being used as a communications
> mechanism between two threads (i.e. to wake up another thread and tell
> it data is ready to be worked on). However, the scheduler currently
> only preempts if the new thread's priority is greater than that of the
> instigator. In cases like this though, it's entirely possible the two
> threads will be of equal priority, and as such that strategy might
> result in undesired latency on waking up the recipient since the
> sender will be allowed the rest of its timeslice.

Please keep in mind that lower latencies are bought with additional 
scheduling overhead and lower throughput. When both threads have the same 
priority, there's simply no rectification for doing that. Unless you base the 
decision on additional criteria like overall/current run/waittime of the 
involved threads (i.e. fairness criteria) or to-be-introduced special 
attributes/properties of locking primitives (e.g. an "interactivity buff").

> However, at the same
> time, if we did signal preemption on equal priority, there's still no
> guarantee that the target thread will in fact be the one woken up due
> to a) the 20% random factor we use for priority skipping, and b) the
> fact that we enqueue new threads at the end of the list of waiting
> threads at the same priority, and as such if another is waiting it
> will go first (if it goes at all). Is this a situation we want to deal