This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 03/11] Add external interface changes: new lock types for pthread_mutex_t
- From: Andi Kleen <andi at firstfloor dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, libc-alpha at sourceware dot org, Andi Kleen <ak at linux dot jf dot intel dot com>
- Date: Fri, 14 Jun 2013 15:17:29 +0200
- Subject: Re: [PATCH 03/11] Add external interface changes: new lock types for pthread_mutex_t
- References: <1370969416-8337-1-git-send-email-andi at firstfloor dot org> <1370969416-8337-4-git-send-email-andi at firstfloor dot org> <1371140842 dot 16968 dot 19094 dot camel at triegel dot csb> <20130613211520 dot GP6123 at two dot firstfloor dot org> <1371192753 dot 16968 dot 19724 dot camel at triegel dot csb>
> Yes, I'm aware of this. And that's an unfortunate situation to be in,
> but I don't see another way to ensure that we still comply with the
> POSIX requirements -- we can't just ignore those. Since we had the
> discussion about the semantics months ago, I haven't seen someone else
> suggest a different way to solve this
I don't see this dead lock thing as a requirement (as in likely to
affect any programs). It's simply a bug.
> I think you should also consider the risk of deviating from the POSIX
> semantics: If, for example, distributions do not enable elision because
> they are worried about breaking existing programs, then this will lead
I'm pretty confident that noone interested in real software
will worry about their programs not deadlocking, or rather
taking longer to deadlock (most likely it would deadlock at some point
if you keep executing it, even with lock elision, as there are always
a few aborts over time)
I can clarify it in the documentation though, although I will
expect it will confuse people more than it will help.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.