[lkml]   [2000]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Semaphores used for daemon wakeup
On Wed, Dec 20, 2000 at 02:34:56AM +0100, Daniel Phillips wrote:
> Yes, I see. There are a lot of similarities to the situation I
> described. The main difference between this situation and bdflush is
> that dmabuf_free isn't really waiting on dmabuf_alloc to fullfill a
> condition (other than to get out of its exclusion region) while bdflush
> can have n waiters.
> If I could have a new primitive for this job it would be up_down(sem1,
> sem2), atomic with respect to a sleeper on sem1. And please give me an
> up_all for good measure. Then for a task wanting to wait on bdflush I
> could write:
> up_down(&bdflush_request, &bdflush_waiter);
> And in bdflush, just:
> up_all(&bdflush_waiter);
> down(&bdflush_request);

I believe that this would look like the following on ptx (omitting all the
obvious stuff :-)

lock_t bdflush_lock;
sema_t bdflush_request;
sema_t bdflush_waiters;
init_sema(&bdflush_request, 0);
init_sema(&bdflush_waiters, 0);

(void) p_lock(&bdflush_lock, SPLBUF);
p_sema_v_lock(&bdflush_waiters, PZERO, &bdflush_lock);

spl_t s;
s = p_lock(&bdflush_lock, SPLFS);
v_lock(&bdflush_lock, s);

if (!flushed || ...

Once more, the use of p_sema_v_lock() avoids races.

> > One can argue the relative merits of the different approaches. I suspect that
> > the above code is less bus-intensive relative to the atomic inc/dec/count ops,
> > but I may be wrong.
> I couldn't say, because your mechanism would need to be elaborated a
> little to handle bdflush's multiple waiters, and I don't know exactly
> what your up_and_wait would look like. Do spinlocks work for bdflush,
> or would you have to go to semaphores? (If the latter you arrive at my
> up_down primitive, which is interesting.) It's even hard to say whether
> my approach is faster or slower than the existing approach. Ultimately,
> up() calls wake_up() and down() calls both add_wait_queue() and
> remove_wait_queue(), so I lose a little there. I win in the common case
> of the non-blocking wakeup, which normally runs through Ben Lahaises's
> lovingly handcrafted fast path in up(), whereas the existing code uses
> the more involved wake_up_process(). What's clear is, they are all
> plenty fast enough for this application, and what I'm really trying for
> is readability.

The above hopefully elaborates a little. I'm more than happy to give further
details etc. assuming it's not boring everybody to tears :-)
I agree with you that your changes improve the readability significantly.


Tim Wright - or or
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:52    [W:0.116 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site