Re: [PATCH] Lightweight userspace semaphores...

[Rusty Russell <rusty@rustcorp.com.au>]

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.