Re: [RFC] Semaphores used for daemon wakeup

[Daniel Phillips <phillips@innominate.de>]

Tim Wright wrote:
> 
> On Fri, Dec 22, 2000 at 12:46:28PM +0100, Daniel Phillips wrote:
> [...]
> > Granted, it's just an example, but it doesn't make sense to wake up more
> > dmabuf_alloc waiters than you actually have buffers for.  You do one
> > up() per freed buffer, and the semaphore's wait queue better be fifo or
> > have some other way of ensuring a task doesn't languish there.  (I don't
> > know, does it?)
>
> ...You are correct - it doesn't
> make sense to wake up more waiters than you can satify if you know this at
> the time. As Paul mentioned, the idea here is that we may have freed
> multiple buffers, and so we wake all the consumers and let them fight it out.

With my model, if you were freeing several buffers you'd do several ups,
and especially in the common case where nobody is waiting that's
efficient enough that it would be hard to justify optimizing further
with say, an up_many(sem, n).

> At least in DYNIX/ptx, semaphores are exclusively FIFO. This gives wake-one
> semantics by default, and prevents starvation.

Then it's most probably that way in Linux too, but __wake_up_common will
take a little time to digest.

> One general rule to remember is that if you need to take multiple locks, then
> you need to always take them in the same order to avoid deadlocks.

Yes, I picked that one up while working on tailmerging and had to lock
multiple inodes.  Then I changed the design so it only takes one lock at
a time - what an improvement.  The moral of this story is that the best
lock is the one you never have to take.

> One simple, if crude way of doing this if they're not two fixed locks is to
> always take the lock with the lower address first. I don't know if this
> will help in this case, but it looks like you probably have to play with
> the rw locks for the wait queues to make this atomic.

I took a look at the code... the implementation details of these
primitives are a whole nuther world.  There's probably a simple
implementation of up_down but I'm far from being able to see it at this
point.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/