On Thu, Dec 21, 2000 at 01:30:03PM -0600, Paul Cassella wrote:
> The mechanism being developed here seems a lot like synchronization
> variables (aka condition variables), which are a part of the "monitor"
> synchronization construct. There is a simple implementation of them in
> the xfs patch.
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
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
Paul Cassella wrote:
> > dmabuf_alloc(...)
> > {
> > while (1) {
> > spin_lock(&dmabuf_lock);
> > attempt to grab a free buffer;
> > spin_unlock(&dmabuf_lock);
> > if (success)
> >
On Fri, 22 Dec 2000, Daniel Phillips wrote:
> But isn't this actually a simple situation? How about:
I had only adapted that example because it had already been posted showing
one way to do it, and so provided something to compare the sv approach to.
> dmabuf_alloc(...)
> {
>
Paul Cassella wrote:
> The sync variable version of the dmabuf code snippet (assuming the
> dmabuf_mutex is never acquired from an interrupt) would look like this:
>
> dmabuf_init(...);
> {
> ...
> spin_lock_init(&dmabuf_spin);
> sv_init(&dmabuf_sv, &dm
Paul Cassella wrote:
> > int atomic_read_and_clear(atomic_t *p)
> > {
> > int n = atomic_read(p);
> > atomic_sub(p, n);
> > return n;
> > }
>
> I don't think this will work; consider two callers doing the atomic_read()
> at the same time, or someone else doing an atomic_de
Looks good.
I'd like to play with you patch, but certainly from a first glance, it would
seem to be sufficiently powerful, and significantly cleaner/clearer (at least
to me :-) than the current mechanism involving the wait queue games.
Regards,
Tim
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL P
The mechanism being developed here seems a lot like synchronization
variables (aka condition variables), which are a part of the "monitor"
synchronization construct. There is a simple implementation of them in
the xfs patch. I've been working on a more general version in order to
aid porting som
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 tha
Tim Wright wrote:
>
> Hi Daniel,
> On Tue, Dec 19, 2000 at 02:11:16PM +0100, Daniel Phillips wrote:
> [...]
> > I'm curious, is my method of avoiding the deadlock race the same as
> > yours? My solution is to keep a count of tasks that 'intend' to take
> > the down():
> >
> > atomic_inc(
Hi Daniel,
On Tue, Dec 19, 2000 at 02:11:16PM +0100, Daniel Phillips wrote:
[...]
> I'm curious, is my method of avoiding the deadlock race the same as
> yours? My solution is to keep a count of tasks that 'intend' to take
> the down():
>
> atomic_inc(&bdflush_waiters);
> up(&bdf
Tim Wright wrote:
>
> On Sun, Dec 17, 2000 at 01:06:10PM +0100, Daniel Phillips wrote:
> > This patch illustrates an alternative approach to waking and waiting on
> > daemons using semaphores instead of direct operations on wait queues.
> > The idea of using semaphores to regulate the cycling of
Daniel Phillips wrote:
> The idea of using semaphores to regulate the cycling of a daemon was
> suggested to me by Arjan Vos.
Actually, his name is Arjan van de Ven - sorry Arjan :-o
Thanks also to Phillip Rumpf for auditing this patch for cross-platform
correctness.
--
Daniel
-
To unsubscribe
On Sun, Dec 17, 2000 at 01:06:10PM +0100, Daniel Phillips wrote:
> This patch illustrates an alternative approach to waking and waiting on
> daemons using semaphores instead of direct operations on wait queues.
> The idea of using semaphores to regulate the cycling of a daemon was
> suggested to m
On Sun, 17 Dec 2000, Daniel Phillips wrote:
> This patch illustrates an alternative approach to waking and waiting on
> daemons using semaphores instead of direct operations on wait queues.
> The idea of using semaphores to regulate the cycling of a daemon was
> suggested to me by Arjan Vos. The
16 matches
Mail list logo
