Introduce down_interruptible_timeout() using timers to make the waiter
stop waiting by simulating a signal (see first patch for more
details). As well introduce asm-generic/semaphore.h and make other
architectures use it too.
--
Inaky
On Mon, Feb 26, 2007 at 04:13:38PM -0800, [email protected] wrote:
> Introduce down_interruptible_timeout() using timers to make the waiter
> stop waiting by simulating a signal (see first patch for more
> details). As well introduce asm-generic/semaphore.h and make other
> architectures use it too.
What do you want this for? Do you really need a full counting semaphore
or do you actually want a mutex?
On Monday 26 February 2007 16:33, Christoph Hellwig wrote:
> On Mon, Feb 26, 2007 at 04:13:38PM -0800, [email protected] wrote:
> > Introduce down_interruptible_timeout() using timers to make the waiter
> > stop waiting by simulating a signal (see first patch for more
> > details). As well introduce asm-generic/semaphore.h and make other
> > architectures use it too.
>
> What do you want this for? Do you really need a full counting semaphore
> or do you actually want a mutex?
Yeah, I need semaphore. This is a hw register that says when the hw
is ready to accept a new command. Code that wants to send commands has
to down the semaphore and then send it. When hw is ready to get a new
command, it sends and IRQ and the IRQ up()s the semaphore.
Now, we don't want to hang on that down() forever if the hw spaces out.
If we get a timeout, we can try recovery actions (like resetting it,
for sake of being polite).
I use this in the WHCI Ultra Wide Band radio controller code (coming soon
to a hw store near you).
Cristoph, I still wonder how the hell you do it to spot every message
that comes into lkml -- I bet you have a cluster of employees using your
name doing it... :)
-- Inaky
> Yeah, I need semaphore. This is a hw register that says when the hw
> is ready to accept a new command. Code that wants to send commands has
> to down the semaphore and then send it. When hw is ready to get a new
> command, it sends and IRQ and the IRQ up()s the semaphore.
So you need a mutex not a semaphore
>
> Now, we don't want to hang on that down() forever if the hw spaces out.
> If we get a timeout, we can try recovery actions (like resetting it,
> for sake of being polite).
Makes sense but you can also do that with mutexes, and its
mutex_interruptible_timeout() you need I suspect ?
Alan
On Monday 26 February 2007 18:18, Alan wrote:
> > Yeah, I need semaphore. This is a hw register that says when the hw
> > is ready to accept a new command. Code that wants to send commands has
> > to down the semaphore and then send it. When hw is ready to get a new
> > command, it sends and IRQ and the IRQ up()s the semaphore.
>
> So you need a mutex not a semaphore
Theoretically I could use a mutex. Practically it would trigger ugly
complications. Only the owner can unlock a mutex (for example), so
I could not unlock from an IRQ handler -- not to mention that the
semantic rules outlined in Documentation/mutex-design.txt explicitly
forbid IRQ usage.
And then, this is what semaphores where designed for, as gates :)
for once that I get to use a semaphore properly...
> On Mon, 26 Feb 2007 16:54:17 -0800 Inaky Perez-Gonzalez <[email protected]> wrote:
> On Monday 26 February 2007 16:33, Christoph Hellwig wrote:
> > On Mon, Feb 26, 2007 at 04:13:38PM -0800, [email protected] wrote:
> > > Introduce down_interruptible_timeout() using timers to make the waiter
> > > stop waiting by simulating a signal (see first patch for more
> > > details). As well introduce asm-generic/semaphore.h and make other
> > > architectures use it too.
> >
> > What do you want this for? Do you really need a full counting semaphore
> > or do you actually want a mutex?
>
> Yeah, I need semaphore. This is a hw register that says when the hw
> is ready to accept a new command. Code that wants to send commands has
> to down the semaphore and then send it. When hw is ready to get a new
> command, it sends and IRQ and the IRQ up()s the semaphore.
>
> Now, we don't want to hang on that down() forever if the hw spaces out.
> If we get a timeout, we can try recovery actions (like resetting it,
> for sake of being polite).
>
This is a very common pattern - for example, shoving characters down a uart
or a parport. Nobody else has needed to invent new locking infrastructure
to do such things and I'd prefer not to do so now.
Can you not do things more conventionally within that driver? Use
waitqueues for sleeping with timeout, use a spinlock for serialisation
against the device registers. There are squillions of examples in
drivers/*, surely.
Hi Inaky,
On Tuesday, 27. February 2007, Inaky Perez-Gonzalez wrote:
> On Monday 26 February 2007 18:18, Alan wrote:
> > > Yeah, I need semaphore. This is a hw register that says when the hw
> > > is ready to accept a new command. Code that wants to send commands has
> > > to down the semaphore and then send it. When hw is ready to get a new
> > > command, it sends and IRQ and the IRQ up()s the semaphore.
> >
> > So you need a mutex not a semaphore
>
> Theoretically I could use a mutex. Practically it would trigger ugly
> complications. Only the owner can unlock a mutex (for example), so
> I could not unlock from an IRQ handler -- not to mention that the
> semantic rules outlined in Documentation/mutex-design.txt explicitly
> forbid IRQ usage.
>
> And then, this is what semaphores where designed for, as gates :)
> for once that I get to use a semaphore properly...
But they are not required for that :-)
I would suggest to use an irq-safe spinlock for the hardware access
and a status indicator (ready for command), if this is really just a command register.
If the status indicator is updated (in IRQ) and read under spinlock, that is safe.
If that command sending is speed critical, please try a FIFO and batch that stuff.
Timeout based locking mechanisms are flawed, because they introduce the hard to find
timing sensitive bugs.
Please try sth. different (e.g. like suggested above).
Semaphores aren't good "busy/ready flags", as you might have already noticed.
Many Thanks and Best Regards
Ingo Oeser, the down{_interruptible,}_timeout() implementation of Linux :-)