mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
To: Alon Ziv <alonz@nolaviz.org>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Mike Kravetz <mkravetz@sequent.com>,
	Ulrich Drepper <drepper@cygnus.com>,
	Linus Torvalds <torvalds@transmeta.com>
Subject: Re: light weight user level semaphores
Date: Thu, 19 Apr 2001 11:08:51 +0200	[thread overview]
Message-ID: <20010419110851.I682@nightmaster.csn.tu-chemnitz.de> (raw)
In-Reply-To: <Pine.LNX.4.31.0104171200220.933-100000@penguin.transmeta.com> <m33db680h8.fsf@otr.mynet.cygnus.com> <023c01c0c8a9$a4bb9940$910201c0@zapper>
In-Reply-To: <023c01c0c8a9$a4bb9940$910201c0@zapper>; from alonz@nolaviz.org on Thu, Apr 19, 2001 at 10:20:48AM +0200

On Thu, Apr 19, 2001 at 10:20:48AM +0200, Alon Ziv wrote:
> My lightweight-semaphores were actually even simpler in userspace:
> * the userspace struct was just a signed count and a file handle.
> * Uncontended case is exactly like Linus' version (i.e., down() is decl +
> js, up() is incl()).
> * The contention syscall was (in my implementation) an ioctl on the FH; the
> FH was a special one, from a private syscall (although with the new VFS I'd
> have written it as just another specialized FS, or even referred into the
> SysVsem FS).

This is roughly the way I would prefer it. 

But I would dedicate a whole page to this struct, since this is
the granularity we can decide sharing on. This also has the
advantage, that we can include a lot of debugging info into this
page, too. Some people would like to know current contenders,
up/down ratio per second and contender etc.

Why? We have the infrastructure and all the semantics already in
place and it is well known to the programmers. We know how we
inherit this stuff, what will happen on process termination and
so on.

I thought about this myself a lot, but just didn't like the idea
to trust user space for up/down. I thought about abusing read() and
write() for down() and up(). Just doing it partially in user
space would be an significant speedup, once you got it right.

Maybe we can even combine both of it like this:

Then user space can do:

   /* open or create sema4 with normal open semantics */
   fd=open("/dev/sema4/myone");
   sema4=mmap(NULL,getpagesize(),,,fd,0);

   /* up */
   atomic_inc_and_test_for_zero(sema4) && ioctl(fd,WAKE_SLEEPERS,NULL);

   /* down */
   atomic_dec_and_test_negative(sema4) && ioctl(fd,SLEEP_NOW,NULL);

or 
   /* open or create sema4 with normal open semantics */
   fd=open("/dev/sema4/myone");

   /* up */
   write(fd, NULL,0); /* do the atomic stuff and wakeup in kernel */

   /* this might be stupid, but COULD be implemented */
   /* add 4 items to counter */
   write(fd, NULL, 4); 

   /* down */
   read(sama4, NULL, 0);

We could even do trylock() by default, if we open O_NONBLOCK. Or
we could do trylock sometimes using select() and poll(). This
also makes it easy to add it to existing select() loops like
Motif.

This differences could even be hidden by the libc. IIRC there are
some archs, which cannot do atomic operations without privileged
instructions, which is not acceptable in user space. Also there
are archs, which are not cache coherent (think NUMA) and where
flushing these caches to the other CPUs is privileged. Last but
not least there are clusters with process migration. 

My twofold approach would solve all these problems rather simply.

It would be a libc decision on what to use now. And the libc
knows enough about the application to handle all these cases.

The only thing we still need, is what we do if a contender or
waiter ist killed. Should we send SIGPIPE? Should we simply wake
all the waiters?

And we are not creating a new namespace again, but just use the
standard UN*X one: File name space.

Hopes this "fit into namespace" solution will be considered,
because I don't like to have a new linux-only API with completely
new semantics and things to care in wrappers, even if you don't
use this stuff. 

I also don't like the "kill me if I do a mistake"
that Linus proposed in the "bad_sem" label.

Comments? Flames? Overengineered?

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
         <<<<<<<<<<<<     been there and had much fun   >>>>>>>>>>>>

  parent reply	other threads:[~2001-04-19  9:09 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20010417114433.D1108@w-mikek2.sequent.com>
2001-04-17 19:48 ` Linus Torvalds
2001-04-18 18:13   ` Bernd Eckenfels
2001-04-18 19:35   ` Ulrich Drepper
2001-04-19  8:20     ` Alon Ziv
2001-04-19  8:52       ` Abramo Bagnara
2001-04-19  9:08         ` Alexander Viro
2001-04-19 10:44           ` Abramo Bagnara
2001-04-19 16:11         ` Linus Torvalds
2001-04-19 16:33           ` Alexander Viro
2001-04-19 16:43             ` Linus Torvalds
2001-04-19 17:33               ` Alexander Viro
2001-04-19 17:38                 ` Linus Torvalds
2001-04-19 18:24                   ` Alexander Viro
2001-04-19 19:26                   ` Ulrich Drepper
2001-04-19 19:35                     ` Alan Cox
2001-04-19 20:06                       ` Ulrich Drepper
2001-04-19 20:11                         ` Alan Cox
2001-04-19 20:26                           ` Ulrich Drepper
2001-04-19 20:22                     ` Ingo Oeser
2001-04-19 20:40                       ` Ulrich Drepper
2001-04-19 20:51                       ` Linus Torvalds
2001-04-19 21:38                       ` Alan Cox
2001-04-19 20:49                     ` Linus Torvalds
2001-04-19 21:18                       ` Ulrich Drepper
2001-04-19 21:41                         ` Linus Torvalds
2001-04-19 22:46                           ` Ulrich Drepper
2001-04-20  1:35                             ` Alexander Viro
2001-04-20  2:45                               ` Ulrich Drepper
2001-04-19 16:43           ` Abramo Bagnara
2001-04-19 20:47           ` Ingo Oeser
2001-04-19 20:54             ` Linus Torvalds
2001-04-19  9:08       ` Ingo Oeser [this message]
2001-04-19 11:51       ` Alan Cox
2001-04-19 16:03       ` Linus Torvalds
2001-04-19 16:38         ` Alan Cox
2001-04-19 16:46           ` Linus Torvalds
2001-04-19 17:12             ` Alan Cox
2001-04-19 22:35               ` Rogier Wolff
2001-04-20  9:29             ` Olaf Titz
2001-04-20 14:19               ` Jesse Pollard
2001-04-20 18:36                 ` Olaf Titz
2001-04-20 23:33               ` Linus Torvalds
2001-04-21  4:06                 ` fd allocation [was: light weight user level semaphores] Edgar Toernig
2001-04-22  9:48                   ` Olaf Titz
2001-04-22 11:41                     ` light weight user level semaphores Alon Ziv
2001-04-22 12:44                       ` Alan Cox
2001-04-22 15:19                         ` Alon Ziv
2001-04-22 14:31                           ` Alexander Viro
2001-04-22 16:08                             ` Alon Ziv
2001-04-22 11:41                     ` Alon Ziv
2001-04-22 14:18                     ` David Woodhouse
2001-04-23 13:19                       ` David Howells
2001-04-23 14:48                         ` Alon Ziv
2001-04-23 15:40                           ` David Howells
2001-04-21 10:13                 ` Olaf Titz
2001-04-23 15:34                 ` Jeff Garzik
2001-04-23 19:18             ` Ingo Oeser
2001-04-24  0:19             ` David Wagner
2001-04-24  0:41               ` Alexander Viro
2001-04-19 19:47           ` Ulrich Drepper
2001-04-19 18:48         ` Olaf Titz
2001-04-19 13:59 George Talbot

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=20010419110851.I682@nightmaster.csn.tu-chemnitz.de \
    --to=ingo.oeser@informatik.tu-chemnitz.de \
    --cc=alonz@nolaviz.org \
    --cc=drepper@cygnus.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkravetz@sequent.com \
    --cc=torvalds@transmeta.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

all inboxes | Powered by JetHome®