[lkml]   [2002]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Lightweight userspace semaphores...
On Mon, 25 Feb 2002 10:00:25 -0500
Hubertus Franke <> wrote:

> Rusty, since I supplied one of those packages available under
> 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


> (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,
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.140 / U:5.544 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site