Messages in this thread | | | Date | Sun, 09 Nov 2003 11:41:07 +0100 | From | Manfred Spraul <> | Subject | Re: prepare_wait / finish_wait question |
| |
Andrew Morton wrote:
>Manfred Spraul <manfred@colorfullife.com> wrote: > > >>Hi Ingo, >> >>sysv semaphores show the same problem you've fixed for wait queue with >>finish_wait: >> >> > >Was me, actually. > > Ups, sorry.
>It would be neater to remove the task from the list _before_ waking it up. >The current code in there is careful to only remove the task if the wakeup >attempt was successful, but I have a feeling that this is unnecessary - the >waiting task will do the right thing. One would need to think about that a >bit more. > > Doesn't work: the woken up thread could be woken up by chance through a signal, and then the task structure could go out of scope while wake_up is still running - oops. Seen on s390 with sysv msg.
>>I wrote a patch for sysv sem and on a 4x Pentium 3, 99.9% of the calls >>hit the fast path, but I'm a bit afraid that monitor/mwait could be so >>fast that the fast path is not chosen. >> >> > >Is it not the case that ia32's reschedule IPI is async? If the >architecture's reschedule uses a synchronous IPI then it could indeed be >the case that the woken CPU gets there first. > poll_idle polls the need_resched flag, and next generation pentium 4 cpus will poll the need_resched flag with the MONITOR/MWAIT instructions. We cannot rely on the async IPI.
>>I'm thinking about a two-stage algorithm - what's your opinion? >> >> > >Instrumentation on other architectures would be interesting. > > The patch already contains the instrumentation - it only needs testing.
-- Manfred
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |