public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@innominate.de>
To: Paul Cassella <pwc@sgi.com>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] Semaphores used for daemon wakeup
Date: Fri, 22 Dec 2000 12:46:28 +0100	[thread overview]
Message-ID: <3A433F14.3F3871A5@innominate.de> (raw)
In-Reply-To: <3A42B353.D0D249C1@innominate.de> <Pine.LNX.4.21.0012212221220.32526-100000@mindy.americas.sgi.com>

Paul Cassella wrote:
> >     dmabuf_alloc(...)
> >     {
> >             while (1) {
> >                     spin_lock(&dmabuf_lock);
> >                     attempt to grab a free buffer;
> >                     spin_unlock(&dmabuf_lock);
> >                     if (success)
> >                            return;
> >                     down(&dmabuf_wait);
> >             }
> >     }
> 
> >     dmabuf_free(...)
> >     {
> >             spin_lock(&dmabuf_lock);
> >             free up buffer;
> >             spin_unlock(&dmabuf_lock);
> >             up(&dmabuf_wait);
> >     }
> 
> This does things a little differently than the way the original did it.
> I thought the original implied that dmabuf_free() might free up multiple
> buffers.  There's no indication in the comments that this is the case, but
> the original, by using vall_sema(), wakes up all dmabuf_alloc()'s that had
> gone to sleep.

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?)
 
> The example wasn't meant to be an ideal use of sv's, but merely as an
> example of how they could be used to achieve the same behavior as the code
> that was posted.

Yes, and a third example of the 'unlock/wakeup_and_sleep' kind of
primitive - there seems to be a pattern.  I should at least take a look
and see if up_down is easy or hard to implement.

--
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/

  reply	other threads:[~2000-12-22 12:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3A42380B.6E9291D1@sgi.com>
2000-12-21 19:30 ` [RFC] Semaphores used for daemon wakeup Paul Cassella
2000-12-21 22:19   ` Tim Wright
2000-12-22  1:12   ` Daniel Phillips
2000-12-22  1:50   ` Daniel Phillips
2000-12-22  4:26     ` Paul Cassella
2000-12-22 11:46       ` Daniel Phillips [this message]
2000-12-22 15:33         ` Tim Wright
2000-12-22 17:25           ` Daniel Phillips
2000-12-22 17:32   ` Brian Pomerantz
2000-12-17 12:06 Daniel Phillips
2000-12-19  0:14 ` Nigel Gamble
2000-12-19  3:34 ` Tim Wright
2000-12-19 13:11   ` Daniel Phillips
2000-12-19 16:07     ` Tim Wright
2000-12-20  1:34       ` Daniel Phillips
2000-12-21 16:28         ` Tim Wright
2000-12-19  9:01 ` Daniel Phillips

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A433F14.3F3871A5@innominate.de \
    --to=phillips@innominate.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pwc@sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox