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. - 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/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:38 EST