* Andi Kleen <[email protected]> wrote:
> On Wednesday 15 February 2006 20:49, Christopher Friesen wrote:
>
> > The goal is for the kernel to unlock the mutex, but the next task to
> > aquire it gets some special notification that the status is unknown. At
> > that point the task can either validate/clean up the data and reset the
> > mutex to clean (if it can) or it can give up the mutex and pass it on to
> > some other task that does know how to validate/clean up.
>
> The "send signal when any mapper dies" proposal would do that. The
> other process could catch the signal and do something with it.
the last time we had special signals for glibc-internal purpose it was
called 'LinuxThreads'. The concept sucked big big time. Using internal
signals means playing with the signal mask - this could conflict with
the application, etc. etc. It's simply out of question to play signal
games. Not to mention the problem of multiple mappers dying. Should thus
queued signals be used? How about if the signal queue overflows.
Signals are really not for stuff like this. Signals are an old,
semantics-laden and thus fragile concept that are not suited for
abstractions like that.
Another flaw with your suggestion is that the mapper _might not know_ at
the time of mmap() that this memory includes a robust futex. So that
brings us back to the per-lock registration syscall approach (and
overhead) that our patch avoids. Furthermore, glibc would have to track
whether a thread used a robust mutex for the first time - which means
external object to pthread_mutex_t - additional complications, overhead
and design weaknesses.
If you take a look at the list-based robust futex code and the concept,
you'll see that a lightweight userspace list of futexes, optionally
parsed by the kernel, mixes very well with the existing futex philosophy
and methodology. It doesnt have any of these complications and
cornercases, precisely because its design aligns naturally with the
futex philosophy: futexes are primarily memory based objects. They are
not signals. They are not in-kernel structures. They are primarily a
piece of userspace memory.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
