Re: making GStaticMutexes faster
- From: Sander Vesik <Sander Vesik Sun COM>
- To: Owen Taylor <otaylor redhat com>
- Cc: gtk-devel-list gnome org
- Subject: Re: making GStaticMutexes faster
- Date: Wed, 9 May 2001 20:59:10 +0100 (BST)
On 9 May 2001, Owen Taylor wrote:
[snip]
> I think "cache coherence" is a topic, not a particular property...
> 
> The particular property you are proposing relying on is if processor
> #1 writes location A and then location B, then another processor will
> never see a write to location B then a write to location A.
> 
> (Since the writes are here separated by a function return it is
> pretty unlikely that instruction reordering would cause problems,
> so it probably is mostly a question of cache behavior, yes.)
> 
Well, modern RISC processors aren't really under pretty much any
constraints to re-ordering writes. Unless you use memory barriers and/or
special setup in page tables.
> I don't have any more information than what I had back when we
> originally discussed this topic, which is that it is not safe
> "in general" without an explicit memory barrier, and it is safe 
> on the common ia32 processors. I still have no idea on what
> set of processors / machines it will fail on.
> 
[snip]
> How common are such platforms?
> 
Off the top of my head, doing so (meaning "without memory barriers") is
not safe on:
	* PPC
	* UltraSparc
	* Alpha
I am somewhat doubtful if it would work on MIPS. Not sure about IA64/HP-PA
but I somewhy really doubt they give promises about write ordering.
>
>                                         Owen
> 
	Sander
One day a tortoise will learn to fly
	-- Terry Pratchett, 'Small Gods'
[
Date Prev][
Date Next]   [
Thread Prev][
Thread Next]   
[
Thread Index]
[
Date Index]
[
Author Index]