All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Christoph Hellwig <hch@infradead.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	Arjan van de Ven <arjanv@infradead.org>,
	Nicolas Pitre <nico@cam.org>,
	Jes Sorensen <jes@trained-monkey.org>,
	Zwane Mwaikambo <zwane@arm.linux.org.uk>,
	Oleg Nesterov <oleg@tv-sign.ru>,
	David Howells <dhowells@redhat.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Benjamin LaHaise <bcrl@kvack.org>,
	Steven Rostedt <rostedt@goodmis.org>, Andi Kleen <ak@suse.de>,
	Russell King <rmk+lkml@arm.linux.org.uk>
Subject: Re: [patch 5/9] mutex subsystem, core
Date: Thu, 22 Dec 2005 13:52:55 +0100	[thread overview]
Message-ID: <20051222125255.GA21661@elte.hu> (raw)
In-Reply-To: <20051222115753.GB30964@infradead.org>


* Christoph Hellwig <hch@infradead.org> wrote:

> > +#include <linux/config.h>
> 
> we don't need config.h anymore, it's included implicitly now.

thanks, fixed.

> > +#include <asm/atomic.h>
> 
> Any chance we could include this after the <linux/*.h> headers ?

done.

> > +#include <linux/spinlock_types.h>
> 
> What do we need this one for?

for:

        spinlock_t              wait_lock;

> > +struct mutex {
> > +	// 1: unlocked, 0: locked, negative: locked, possible waiters
> 
> please use /* */ comments.

done.

> 
> > +	atomic_t		count;
> > +	spinlock_t		wait_lock;
> > +	struct list_head	wait_list;
> > +#ifdef CONFIG_DEBUG_MUTEXES
> > +	struct thread_info	*owner;
> > +	struct list_head	held_list;
> > +	unsigned long		acquire_ip;
> > +	const char 		*name;
> > +	void			*magic;
> > +#endif
> > +};
> 
> I know we generally don't like typedefs, but mutex is like spinlocks 
> one of those cases where the internals should be completely opaqueue, 
> so a mutex_t sounds like a good idea.

yeah, but we have DEFINE_MUTEX ...

> > +#include <linux/syscalls.h>
> 
> What do you we need this header for?

correct, fixed.

> > +static inline void __mutex_lock_atomic(struct mutex *lock)
> > +{
> > +#ifdef __ARCH_WANT_XCHG_BASED_ATOMICS
> > +	if (unlikely(atomic_xchg(&lock->count, 0) != 1))
> > +		__mutex_lock_noinline(&lock->count);
> > +#else
> > +	atomic_dec_call_if_negative(&lock->count, __mutex_lock_noinline);
> > +#endif
> > +}
> 
> this is the kind of thing I meant in the comment to the announcement.

i've solved that via the CONFIG_MUTEX_XCHG_ALGORITHM switch. It's more 
maintainable than 23 asm-*/mutex.h's.

> Just having this in arch code would kill all these ifdefs over mutex.c

it's exactly 3 #ifdefs.

	Ingo

  reply	other threads:[~2005-12-22 12:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-22 11:42 [patch 5/9] mutex subsystem, core Ingo Molnar
2005-12-22 11:57 ` Christoph Hellwig
2005-12-22 12:52   ` Ingo Molnar [this message]
2005-12-22 13:38 ` Oleg Nesterov
2005-12-22 14:46   ` Ingo Molnar
2005-12-22 16:12     ` Oleg Nesterov

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=20051222125255.GA21661@elte.hu \
    --to=mingo@elte.hu \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjanv@infradead.org \
    --cc=bcrl@kvack.org \
    --cc=dhowells@redhat.com \
    --cc=hch@infradead.org \
    --cc=jes@trained-monkey.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nico@cam.org \
    --cc=oleg@tv-sign.ru \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@osdl.org \
    --cc=zwane@arm.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.