From: Roland Dreier <rdreier@cisco.com>
To: "Matt Turner" <mattst88@gmail.com>
Cc: linux-kernel@vger.kernel.org,
"Ivan Kokshaysky" <ink@jurassic.park.msu.ru>,
rth@twiddle.net, "Jay Estabrook" <jay.estabrook@hp.com>
Subject: Re: questions about native alpha futex implementation
Date: Wed, 17 Dec 2008 11:26:47 -0800 [thread overview]
Message-ID: <adaprjqzjpk.fsf@cisco.com> (raw)
In-Reply-To: <b4198de60812171113r72d8d04ao67cde38c62185bcc@mail.gmail.com> (Matt Turner's message of "Wed, 17 Dec 2008 14:13:15 -0500")
> Alpha uses a generic futex implementation, which causes some problems [1].
Summarizing this: the generic futex implementation leaves
futex_atomic_cmpxchg_inatomic() as a stub that just returns -ENOSYS, and
glibc robust futex code can't handle this return value, which leads to
glibc tests hanging.
> I've read through the code, and it appears as if the implementation
> could be done by using the ldq_l/stq_c instructions, relatively easy I
> might add. I'm definitely interested in implementing this, but first...
>
> I have only a few questions.
>
> 1) What are the benefits of a native futex implementation, other than
> fixing the glibc test failures?
Presumably native implementations can use optimized assembly, which
would be somewhat faster than a generic implementation in C.
> 2) Is there a technical reason it hasn't been implemented on Alpha?
I don't know for sure, but I would guess it's just that no one has cared
enough about optimizing futexes on alpha.
A native implementation for alpha is probably an amusing project, but
also figuring out a way of implementing the missing operations for
generic futexes would be nice too (given that glibc uses them now).
Although a generic futex_atomic_cmpxchg_inatomic() that works for SMP
might be tricky.
- R.
next prev parent reply other threads:[~2008-12-17 19:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-17 19:13 questions about native alpha futex implementation Matt Turner
2008-12-17 19:26 ` Roland Dreier [this message]
2008-12-17 21:46 ` Richard Henderson
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=adaprjqzjpk.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=ink@jurassic.park.msu.ru \
--cc=jay.estabrook@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mattst88@gmail.com \
--cc=rth@twiddle.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.