On Thursday 07 March 2002 07:40 am, Peter Wächtler wrote:
> Rusty Russell wrote:
> > This is a userspace implementation of rwlocks on top of futexes.
>
> With the futex approach in mind: Does anybody think it's desirable to have
>
> pthread_cond_wait/signal and pthread_mutex_* with inter process scope build
> into the kernel as system call?
>
Yes, I talked with Bill Abt from IBM's NPthreads package about it in
December. Huge value as it would provide full POSIX compliants.
There are differences whether you have a 1:1 threading model or
a M:N threading model.
Eitherway this could be implemented using futexes.
M:N is surely more tricky. The problem is that the calling process/kernel
thread can not be blocked but has to return to user level to continue another
user level thread. What needs to happen is something like a signaling
mechanism.
> The only issue I see so far, is that libpthread should get a "reserved"
> namespace entry ( /dev/shm/.linuxthreads-locks ?) to hold all the
> PTHREAD_PROCESS_SHARE locks/condvars.
>
> OTOH Irix seems to implement inter process locks as syscall, so that the
> kernel does all the bookkeeping. That approach denies a malicious program
> to trash all locks in the system...
>
> Hmh, then we could implement a per user /dev/shm/.linuxthreads-lock-<uid>
> with tight permissions?
>
> What do you think?
-- -- Hubertus Franke (frankeh@watson.ibm.com) - 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:01:03 EST