Re: [PATCH] Lightweight userspace semaphores...

Rusty Russell (rusty@rustcorp.com.au)
Wed, 27 Feb 2002 11:24:17 +1100


On Mon, 25 Feb 2002 10:00:25 -0500
Hubertus Franke <frankeh@watson.ibm.com> wrote:

> Rusty, since I supplied one of those packages available under lse.sourceforge.net
> let me make some comments.
>
> (a) why do you need to pin. I simply use the user level address (vaddr)
> and hash with the <mm,vaddr> to obtain the internal object.
> This also gives me full protection through the general vmm mechanisms.

I pin while sleeping for convenience, so I can get a kernel address. It's
only one page (maybe 2). I could look up the address every time, but then I
need to swap the page back in anyway to look at it.

> (b) I like the idea of mmap or shmat with special flags better than going
> through a device driver.

Me too, but I'd rather have people saying "make it a syscall" than "eww...
not another special purpose syscall!" 8)

> (c) creation can be done on demand, that's what I do. If you never have
> to synchronize through the kernel than you don't create the objects.
> There should be an option to force explicite creation if desired.

Absolutely, except there is no real "creation" event. Adding a "here be
semaphores" syscall is sufficient and useful (and also makes it easy to
detect that there is no FUS support in the kernel).

> (d) The kernel should simply provide waiting and wakeup functionality and
> the bean counting should be done in user space. There is no need to
> pin or crossmap.

See above.

> (e) I really like to see multiple reader/single writer locks as well. I
> implemented these

Hmmm... my current implementatino only allows down one and up one
operations, but off the top of my head I don't see a no reason this couldn't
be generalized. Then:
1) Initialize at INT_MAX
2) down_read = down 1
3) down_write = down INT_MAX

Sufficient?

> (f) I also implemented convoy avoidance locks, spinning versions of
> user semaphores. All over the same simple interface.
> ulocks_wait(read_or_write) and ulocks_signal(read_or_write, num_to_wake_up).
> Ofcourse to cut down on the interface a single system call is enough.

Interesting. Something like this might be needed for backwards
compatibility anyway (spin & yield, at least).

> (g) I have an extensive test program and regression test <ulockflex>
> that exercises the hell out of the userlevel approach.

Excellent. I shall grab it and take a look!

Thanks for the feedback,
Rusty.

-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/