Re: [PATCH v5] introduce macro spin_event_timeout()

[Scott Wood <scottwood@freescale.com>]

Timur Tabi wrote:
> On Wed, Mar 11, 2009 at 2:22 PM, Scott Wood <scottwood@freescale.com> wrote:
> 
>> I was under the impression that we were only talking about timeouts, and
>> that the common case was significantly shorter than that.
> 
> I think one of the concerns that Alan Cox raised is that the existence
> of this macro would encourage people to spin for long durations.

Yes, and I've already stated my response to that line of thinking.  I 
just don't see anyone who would have done something better than a spin 
loop changing their mind because doing a spin loop becomes a little 
easier -- the spin loop is *already* easier than the alternatives.

What if another variant were added that did msleep between iterations, 
for longer expected completion times?  Or if we want to be really fancy, 
combine them into one function that starts with small udelays, then 
switches to msleep of progressively larger intervals up to some maximum?

>> If it's atomic because preemption was disabled, yes -- but even a rare
>> extended spin in such a context would be bad for hard realtime.  If
>> interrupts are disabled, or the code is executing from a timer interrupt (or
>> possibly other interrupts depending on the hardware and its priority
>> scheme), no.
> 
> So in that case, I can't rely on jiffies.  

Or you can say that atomic context is outside the scope of this macro.

-Scott