This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Lock elision test results
- From: Andi Kleen <andi at firstfloor dot org>
- To: libc-alpha at sourceware dot org
- Date: Fri, 05 Jul 2013 18:21:01 -0700
- Subject: Re: Lock elision test results
- References: <20130614102653 dot GA21917 at linux dot vnet dot ibm dot com> <1372767484 dot 22198 dot 4505 dot camel at triegel dot csb> <20130703065355 dot GA4522 at linux dot vnet dot ibm dot com> <1372849432 dot 14172 dot 20 dot camel at triegel dot csb> <20130703120753 dot GA8416 at linux dot vnet dot ibm dot com> <1372857484 dot 14172 dot 195 dot camel at triegel dot csb> <20130704092941 dot GA12864 at linux dot vnet dot ibm dot com>
Dominik Vogt <vogt@linux.vnet.ibm.com> writes:
>
> What I do not understand is why thread 1 starts aborting
> transactions at all. After all there is no conflict in the
> write sets of both threads. The only aborts should occur because
> of interrupts. If once the lock is used unfortunate timing
> conditions force the code to not switch back to elision (because
> one of the thread always uses the lock and forces the other one
> to lock too), that would explain the observed behaviour. But
> frankly that looks to unlikely to me, unless I'm missing some
> important facts.
You'll probably need a hardware profiler to track this down
(assuming you have appropriate events and some way to profile them)
-Andi
--
ak@linux.intel.com -- Speaking for myself only