public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Chris Metcalf <cmetcalf@tilera.com>
To: Roland McGrath <roland@hack.frob.com>
Cc: Maxim Kuvyrkov <maxim@codesourcery.com>,
	Andrew Haley <aph@redhat.com>,	David Miller <davem@davemloft.net>,
	<joseph@codesourcery.com>,	<rdsandiford@googlemail.com>,
	<libc-ports@sourceware.org>,	<libc-alpha@sourceware.org>
Subject: Re: [PATCH] Unify pthread_spin_[try]lock implementations.
Date: Wed, 11 Jul 2012 14:52:00 -0000	[thread overview]
Message-ID: <4FFD931D.4000606@tilera.com> (raw)
In-Reply-To: <20120711112235.B28CA2C099@topped-with-meat.com>

On 7/11/2012 7:22 AM, Roland McGrath wrote:
>> OK, but this will be a change on its own in a follow up patch.  I want to
>> keep this patch just a mechanical change.
> I don't want to put anything in the generic code that isn't clearly correct
> or isn't clearly justified or doesn't have thorough comments explaining any
> nonobvious issues.  So get it right first before the generic code goes in.
> Each machine dropping its old code in favor of the new generic code can
> wait as long as each machine maintainer wants.

And this kind of thing definitely varies by architecture.  For example, on
TILE-Gx the atomic operation is almost as fast as a regular store or load,
since there is no bus locking involved: the atomic instruction is
dispatched over the memory interconnect to the home cache for the address
in question, and returns a result.  However, you definitely don't want to
have dozens and dozens of cores all hammering compare-exchanges into the
memory network, so some kind of backoff turns out to be critical.

In addition, the "test and test-and-set" idiom [1] that is being proposed
here is actually an anti-pattern for Tilera (and likely for any other
cache-coherent mesh-based memory interconnect).  The problem is that each
"test" instruction (i.e. a load) pulls a shared copy of the cache line into
the tester's local cache, and then when some other core does the
test-and-set operation, the first thing done by the home cache is to
invalidate all the shared copies, which is slow and also loads the memory
network unnecessarily.  So plain test-and-set in a loop, with some kind of
backoff (we use bounded exponential backoff) ends up being the best thing
to do.

This isn't to say that the generic version might not be plausible for many
existing architectures, just that it certainly isn't going to be right for
all of them.

[1] http://en.wikipedia.org/wiki/Test_and_Test-and-set

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

  reply	other threads:[~2012-07-11 14:52 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-14  4:36 [PATCH 2/3, MIPS] Rewrite MIPS' pthread_spin_[try]lock using __atomic_* builtins Maxim Kuvyrkov
2012-06-28 23:10 ` Joseph S. Myers
2012-07-11  5:58   ` [PATCH] Unify pthread_spin_[try]lock implementations Maxim Kuvyrkov
2012-07-11  8:15     ` Roland McGrath
2012-07-11  8:25       ` David Miller
2012-07-11  8:44         ` Andrew Haley
2012-07-11  8:54           ` Maxim Kuvyrkov
2012-07-11  9:02             ` Andrew Haley
2012-07-11  9:05               ` Maxim Kuvyrkov
2012-07-11 11:22                 ` Roland McGrath
2012-07-11 14:52                   ` Chris Metcalf [this message]
2012-07-11 22:16                   ` Maxim Kuvyrkov
2012-07-25 18:13                     ` Roland McGrath
2012-07-25 19:04                       ` Chris Metcalf
2012-07-25 20:22                         ` Roland McGrath
2012-07-25 20:29                           ` Chris Metcalf
2012-07-25 20:43                             ` Roland McGrath
2012-08-15  3:17                       ` Maxim Kuvyrkov
2012-08-15 16:27                         ` Roland McGrath
2012-08-15 16:39                           ` Maxim Kuvyrkov
2012-08-15 16:44                             ` Roland McGrath
2012-08-15 16:53                               ` Maxim Kuvyrkov
2012-08-15 16:56                                 ` Roland McGrath
2012-08-15 17:05                                   ` Maxim Kuvyrkov
2012-08-15 17:05                             ` Jeff Law
2012-08-15 17:11                               ` Roland McGrath
2012-08-15 17:24                                 ` Jeff Law
2012-08-15 16:40                         ` Joseph S. Myers
2012-08-15 16:43                         ` Carlos O'Donell
2012-08-15 22:00                         ` Andreas Schwab
2012-08-16 10:21                         ` Torvald Riegel
2012-08-16 12:40                           ` Chris Metcalf
2012-08-22 23:16                           ` Maxim Kuvyrkov
2012-07-11  8:26       ` Maxim Kuvyrkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FFD931D.4000606@tilera.com \
    --to=cmetcalf@tilera.com \
    --cc=aph@redhat.com \
    --cc=davem@davemloft.net \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=libc-ports@sourceware.org \
    --cc=maxim@codesourcery.com \
    --cc=rdsandiford@googlemail.com \
    --cc=roland@hack.frob.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).