Re: Latency: allowing resheduling while holding spin_locks

Roger Larsson wrote: > > On Sunday 14 January 2001 01:06, george anzinger wrote: > > Nigel Gamble wrote: > > > On Sat, 13 Jan 2001, Roger Larsson wrote: > > > > A rethinking of the rescheduling strategy... > > > > > > Actually, I think you have more-or-less described how successful > > > preempti

Re: Latency: allowing resheduling while holding spin_locks

On Sunday 14 January 2001 01:06, george anzinger wrote: > Nigel Gamble wrote: > > On Sat, 13 Jan 2001, Roger Larsson wrote: > > > A rethinking of the rescheduling strategy... > > > > Actually, I think you have more-or-less described how successful > > preemptible kernels have already been develope

Re: Latency: allowing resheduling while holding spin_locks

Nigel Gamble wrote: > > On Sat, 13 Jan 2001, Roger Larsson wrote: > > A rethinking of the rescheduling strategy... > > Actually, I think you have more-or-less described how successful > preemptible kernels have already been developed, given that your > "sleeping spin locks" are really just sleep

Re: Latency: allowing resheduling while holding spin_locks

On Sat, 13 Jan 2001, Roger Larsson wrote: > A rethinking of the rescheduling strategy... Actually, I think you have more-or-less described how successful preemptible kernels have already been developed, given that your "sleeping spin locks" are really just sleeping mutexes (or binary semaphores).

Latency: allowing resheduling while holding spin_locks

Hi, A rethinking of the rescheduling strategy... I have come to this conclusion. A spinlock prevents other processes to enter that specific region. But interrupts are allowed they might delay execution of a spin locked reqion for a undefined (small but anyway) time. Code with critical maximum