Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Feb 2000 19:21:07 -0800
From:      Alfred Perlstein <bright@wintelcom.net>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Chee Wei Ng <scip7050@yahoo.com>, freebsd-smp@FreeBSD.ORG
Subject:   Re: MPrellock_edx
Message-ID:  <20000201192107.I24609@fw.wintelcom.net>
In-Reply-To: <200002020230.SAA93312@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, Feb 01, 2000 at 06:30:35PM -0800
References:  <20000202010550.16864.qmail@web112.yahoomail.com> <20000201175008.F24609@fw.wintelcom.net> <200002020230.SAA93312@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew Dillon <dillon@apollo.backplane.com> [000201 18:56] wrote:
>     I discussed this issue with Linus after someone from the linux kernel
>     group brought it up.  Basically we have adopted the same thing that linux
>     uses.
> 
>     Under Intel, the following is true:
> 
> 	* Writes are buffered but are committed to memory in the same
> 	  order they were issued.  Thus write<->write conflicts are not 
> 	  an issue.
> 
> 	* Speculative reads may occur, but they occur from main memory
> 	  into the L1 cache and thus still adhere to L1 cache protocols.
> 	  Thus speculative reads are not an issue.
> 
> 	* The cpu may reorder non-conflicting reads.  A non-conflicting
> 	  read may be reordered from *before* a write to *after* a write,
> 	  or from *after* a write to *before* a write.
> 
> 	  This is an issue.  This is the ONLY issue with intel hardware.
> 
>     The purpose of the locked instruction is to prevent any possibility
>     of reads being reordered from to after the MP lock is released.
                                   ^
                                before ?

So instead of releasing the lock and then writing the the locked object,
you could read from the locked object, release the lock then the read
actually happens after the lock release.

You're not potentially spamming someone else's critical section, but actually
possibly extending your own critical section beyond the point where you've
released the lock violating your own critical section?

-Alfred


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000201192107.I24609>