public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Schnell <mschnell@lumino.de>
To: linux-kernel@vger.kernel.org
Subject: implementing Futex
Date: Thu, 13 Aug 2009 17:03:14 +0200	[thread overview]
Message-ID: <4A842B32.5030401@lumino.de> (raw)

Hi experts,

I am planning to implement a Futex on the upcoming MMU-enabled NIOS
architecture.

I do know that the pure user-space part of the Futex is done in gLibC,
so that pthread_mutex...() automatically uses Futex, if same is
available in the underlying arch, and use some system call it it is not.
But for my first tests, I will not recompile gLibC but I do have a
working (on x86) Futex user code implementation, inspired by Ulrich
Drepper: "Futexes Are Tricky".

One of the tasks is to provide the appropriate atomic user-space
operations for the Futex implementation. I was able to successfully do
this for the x86 user space code and we have been discussing, how to do
 this with other archs.

Now in the Kernel code in "linux-2.6/arch/x86/include/asm/futex.h" there
are two different implementations for some atomic operations for the  Futex:

"futex_atomic_op_inuser()"    and
"futex_atomic_cmpxhg__inatomic()"


"futex_atomic_op_inuser()" seemingly accesses user space data while
being run in Kernel space (doing the .section __ex_table trick).

Questions:

Is this correct ?

In a non-SMP environment do we need to use really atomic code here, or
does futex_atomic_op_inuser() run with interrupt disabled, anyway?

When we are doing futex_atomic_op_inuser(), is this Kernel code running
in system mode so that we can disable the interrupt do protect the
atomic code in a non-SMP System ?

>From reading the code (futex_atomic_op_inuser() seems only to be called
once (in futex.c) ), it seems that futex_atomic_op_inuser() is not
really used at all. It seems that it'd only called for futex_wake, and
here the "Operation" is derived from the last parameter of the system
call, which the man page says is ignored.  So, are all the operations
implemented there really necessary or just "nice to have" ?


I see that futex_atomic_cmpxhg__inatomic() really is used by futex.c

"futex_atomic_cmpxhg__inatomic()" accesses the Futex without doing the
user-space-access-trick, so here, the MMU seems to be in User mode
configuration. So how does the Kernel use it ? (in the CPU's "user mode"
or "System mode", with interrupts enabled or disabled (protected against
concurrent SMP accesses by a spinlock) )

Any pointers ?

Thanks for all answers,
-Michael

             reply	other threads:[~2009-08-13 15:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-13 15:03 Michael Schnell [this message]
2009-08-13 16:39 ` implementing Futex Arnd Bergmann
2009-08-13 17:28   ` Arnd Bergmann
2009-08-14  9:46   ` Michael Schnell
2009-08-14 11:44     ` Arnd Bergmann
2009-08-17  8:57       ` Mike Frysinger
2009-08-14  9:48   ` Michael Schnell
     [not found]   ` <4A8525A1.205@lumino.de>
     [not found]     ` <200908141128.01179.arnd@arndb.de>
2009-08-14 10:03       ` Michael Schnell
2009-08-14 10:11       ` Michael Schnell
2009-08-14 11:55   ` Michael Schnell
2009-08-14 12:38     ` Arnd Bergmann
2009-08-14 12:56       ` Michael Schnell
2009-08-14 13:33         ` Arnd Bergmann
2009-08-31 16:30           ` Darren Hart
2009-08-17  8:50   ` Michael Schnell
2009-08-17 11:53     ` [Nios2-dev] " Michael Schnell

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=4A842B32.5030401@lumino.de \
    --to=mschnell@lumino.de \
    --cc=linux-kernel@vger.kernel.org \
    /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