This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Lock elision implementation guidelines


On Tue, Feb 19, 2013 at 09:52:28PM +0100, Torvald Riegel wrote:
> > > > No. You cannot ignore any requirements. That's why they're called
> > > > requirements and not recommendations.
> > > 
> > > Usually, I wouldn't reconsider any requirements.  But this case is
> > > special enough to warrant thinking about this.
> > 
> > Everybody's pet feature is "special enough" to warrant breaking the
> > requirements -- to them. The problem is that this doesn't scale. You
> > end up breaking all the requirements because everybody wants to break
> > a different one.
> 
> Just a quick comment because this seems to be off-topic: The
> requirements themselves don't come out of thin air either;  Some
> features are considered to be more important than others when deciding
> on the requirements too.  So there is a way to scale such decisions, and
> lock elision has enough potential to be quite a bit more than a pet
> feature.

At present, this feature is only interesting to less than 1% of glibc
users. I doubt that will increase significantly even if the hardware
becomes widespread, simply because locking already costs virtually
nothing for most normal usage cases.

> > If the number of threads that
> > deadlock in a program is bounded, it's not even a resource "leak".
> > This is a very different class of "bug" from what would happen if the
> > thread wrongfully continued execution when it should have deadlocked!
> > The latter would almost certainly lead to undefined behavior, with
> > likely results including data corruption or security compromise.
> > 
> > With that said, I can think of at least several scenarios where the
> > deadlock behavior could be used constructively:
> > 
> > 1. For a permanent thread that does nothing but handle signals using
> > async-signal-safe functions, pthread_mutex_lock(&m);
> > pthread_mutex_lock(&m); is just as valid as for(;;)pause();
> 
> That's a good counter example -- I hadn't thought about signal handling.
> 
> However, is a deadlocked thread actually *required* by POSIX to make
> progress handling signals?

This is a good question -- I'll have to research it. I believe the
general forward progress requirements cover this case: for example if
a signal has been sent to thread A, and thread B is waiting for an
event that would happen from the signal handler running in thread A,
and no other threads exist, then I believe it's required that the
signal handler run. However I can look into this in more detail.

> The same question also applies to program exit: Is a program with a
> deadlock required to exit successfully, or can it deadlock?  I'm

Yes, it can and must exit successfully provided no lock prevents it
from doing so. If _exit is called, there's no question. If exit is
called, then unless the deadlocked thread is holding a lock on a stdio
stream, or unless an atexit handler enters an infinite loop, exit must
eventually terminate the program.

> wondering about this not because I would think that implementations
> should try to deadlock in this case; instead, I'm thinking about whether
> POSIX actually gives sufficient forward progress guarantees in such
> cases to allow the program to depend on them in the scenarios you
> mentioned.

There have actually been some recent discussions on the Austin Group
tracker regarding conditions under which locks (especially stdio
locks) can delay/deadlock exit(). You might want to check them. My
feel is that if you posed a question about whether deadlocked threads
can block exit in other cases, you'd get a clear no from the
committee.

> Nonetheless, for the E use case I think it could still be useful (i.e.,
> allowing users to override the deadlock requirement to get more
> elision).  But I'm not sure whether providing this is really necessary,
> as it would allow experimentation for programs that can't be recompiled.

This override would need to be lock-specific, set via an
attribute/lock-type. Making it globally configurable via a setting
such as an environment variable could introduce dangerous incorrect
behavior into programs which are (rightfully) assuming POSIX
conformance of mutexes. This could be mitigated somewhat by using
secure_getenv but I still think it's a bad idea for environment
variables to break things.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]