Re: Signals and preemption-related question
Ingo Weinhold <[email protected]> Sat, 22 Aug 2009 17:08:13 +0200
| Newsgroups | gmane.os.openbeos.kernel.devel |
|---|---|
| Message-ID | <[email protected]> |
On 2009-08-22 at 01:54:20 [+0200], Rene Gollent <[email protected]> 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 > with, and if so, any thoughts on how? The "20% skip" and "enqueue at the end" are really fairness issues. So, if you're generally concerned about fairness, those should be addressed. I'd rather work on making the affine scheduler more affine first, though. CU, Ingo ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july