This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 4/6] Do not call _xend if no transaction is active.
- From: Andi Kleen <andi at firstfloor dot org>
- To: libc-alpha at sourceware dot org
- Date: Tue, 03 Sep 2013 16:11:21 -0700
- Subject: Re: [PATCH 4/6] Do not call _xend if no transaction is active.
- Authentication-results: sourceware.org; auth=none
- References: <20130902075228 dot GA4792 at linux dot vnet dot ibm dot com> <20130902080450 dot GD4997 at linux dot vnet dot ibm dot com> <87fvtndjks dot fsf at tassilo dot jf dot intel dot com> <20130903074521 dot GC3368 at linux dot vnet dot ibm dot com>
Dominik Vogt <vogt@linux.vnet.ibm.com> writes:
>
> This patch is _not_ about what happens when the user unlocks an
> unlocked lock. It is about what happens when the user unlocks a
> mutex that has been elided, but when at the time of unlock() no
> transaction is open.
That's unlocking a free lock: undefined.
> If all instructions are executed in a row, this is correct code,
> regardless of whether elision is available in foo, in glibc or
> both or not at all. Now consider this:
>
> if (some_condition) goto side_entrance
> foo_lock(x);
> side_entrance:
> phtread_mutex_lock(m);
> foo_unlock(x);
> phtread_mutex_unlock(m);
>
> Under some_condition, the initial foo_lock(x) is skipped. Now
> mutex_lock() starts a transaction, foo_unlock detects an unlocked
> lock and assumes it is elided and calls _xend() and thus commits
> the transaction. The final mutex_unlock() would try to xend the
> assumed transaction and crash.
You're unlocking a free lock in foo. Which I would argue
is broken.
If you want to do that you have to keep track of it somehow
else, not make everyone slower in pthreads.
-Andi
--
ak@linux.intel.com -- Speaking for myself only