Re: [PATCH] Lightweight userspace semaphores...

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

On Mon, 4 Mar 2002 11:51:43 -0500
Hubertus Franke <frankeh@watson.ibm.com> wrote:
> > This is a definite advantage: my old fd-based code never looked at the
> > userspace counter: it had a kernel sempahore to sleep on for each
> > userspace lock. OTOH, this involves kernel allocation, with the complexity
> > that brings.
> > 
> 
> ???, kernel allocation is only required in under contention. If you take a look 
> at how I used the atomic word for semaphores and for rwlock_t, its different. 
> If you recheck in the kernel you need to know how this is used.
> In my approach I simply allocated two queues on demand.

Yes, but no allocation is even better than on-demand allocation, if you can
get away with it.

> I am OK with only supplying semaphores and rwlocks, if there is a general consent
> about it. Nevertheless, I think the multiqueue approach is somewhat more elegant
> and expandable.

Well, it's pretty easy to allow other values than -1/1 later as required.
I don't think the switch() overhead will be measurable for the first dozen
lock types 8).

> > > (h) how do you deal with signals ? E.g. SIGIO or something like it.
> > 
> > They're interruptible, so you'll get -ERESTARTSYS.  Should be fine.
> >  
> 
> That's what I did too, but some folks pointed out they might want to 
> interrupt a waking task, so that it can get back into user space and
> fail with EAGAIN or so and do not automatically restart the syscall.

Sorry, my bad.  I use -EINTR, so they don't get restarted, for exactly that
reason (eg. implementing timeouts on mutexes).

Cheers!
Rusty.
-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.