This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: PATCH: Fix ll/sc for mips (take 3)
- From: Hartvig Ekner <hartvige at mips dot com>
- To: justinca at ri dot cmu dot edu (Justin Carlson)
- Cc: dan at debian dot org (Daniel Jacobowitz), hjl at lucon dot org (H . J . Lu), dom at algor dot co dot uk (Dominic Sweetman), libc-alpha at sources dot redhat dot com (GNU C Library), linux-mips at oss dot sgi dot com
- Date: Tue, 5 Feb 2002 09:39:27 +0100 (MET)
- Subject: Re: PATCH: Fix ll/sc for mips (take 3)
Note that the issue of a "LL" will trigger bus watching activity in the
system logic (and maybe delays?) I would personally try to avoid issuing
"dangling" ll's in the normal case, even though the functionality would
be ok, and in some cases they are inavoidable.
/Hartvig
Justin Carlson writes:
>
> On Mon, 2002-02-04 at 23:47, Daniel Jacobowitz wrote:
> >
> > Won't this cause some gratuitous thrashing if someone else is trying to
> > get the spinlock at the same time?
> >
>
> Actually, if you look at the required semantics of ll, no. A ll by
> itself can never cause a sc from another cpu to fail. It's part of the
> semantic definition to avoid potential livelock cases, e.g.
>
> A does ll
> B does ll, foiling A's lock attempt
> A does sc, which fails
> A does ll, foiling B's lock attempt
> B does sc, which fails
> B does ll, foiling A's lock attempt
> ...
>
> Instead, this case becomes:
> A does ll
> B does ll
> A does sc, which succeeds, even though B has done a ll
> B does sc which fails
> A does critical section work
> B spins on ll until A releases the lock
>
>
> -Justin
>
>
--
_ _ _____ ____ Hartvig Ekner Mailto:hartvige@mips.com
|\ /| | |____)(____ Direct: +45 4486 5503
| \/ | | | _____) MIPS Denmark Switch: +45 4486 5555
T E C H N O L O G I E S http://www.mips.com Fax...: +45 4486 5556