From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [Question] race between spin_lock and spin_unlock
Date: Mon, 24 Jun 2013 17:37:32 +0100 [thread overview]
Message-ID: <20130624163732.GC25582@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <CACVXFVNgONa79n+7Bg4p4Fx568XaK6gy+L9tCrP=CmOGwKY7ig@mail.gmail.com>
On Mon, Jun 24, 2013 at 05:04:37PM +0100, Ming Lei wrote:
> On Mon, Jun 24, 2013 at 11:43 PM, Will Deacon <will.deacon@arm.com> wrote:
> >> Any comments on the problem?
> >
> > Not sure I see the problem -- the sev guaranteed by the unlock is pended on
> > the core doing the lock by setting the event register, so you can't miss it.
> > The wfe will acknowledge the event (by clearing the event register) but it
> > won't actually wait.
>
> If so, looks I am afraid too much, :-)
>
> Also I have another question, if two sev() comes from two cores, then the
> wfe() in one core will acknowledge both the two sev()? or one wfe() only
> acks one sev()?
Events do not compose, so you can only have one event pending at a time,
which the wfe will clear.
> If the wfe() in one core may acknowledge two sev(), the above problem
> might still exists.
You mean, if you had two CPUs spinning on a lock held by a third CPU? In
this case, the third CPU would have to release the lock, then one of the
waiters would have to acquire it, complete its critical section and finally
release it before the other waiter had executed its wfe (about three
instructions)...
I don't think we need to worry about that in practice, unless you have
another example?
Will
next prev parent reply other threads:[~2013-06-24 16:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-24 15:13 [Question] race between spin_lock and spin_unlock Ming Lei
2013-06-24 15:43 ` Will Deacon
2013-06-24 16:04 ` Ming Lei
2013-06-24 16:37 ` Will Deacon [this message]
2013-06-25 4:31 ` Ming Lei
2013-06-25 8:48 ` Will Deacon
2013-06-25 10:54 ` Ming Lei
2013-06-25 10:59 ` Will Deacon
2013-06-25 11:19 ` Ming Lei
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=20130624163732.GC25582@mudshark.cambridge.arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 NNTP newsgroup(s).