By: Tzvetan Mikov (tzvetanmi.delete@this.yahoo.com), October 23, 2006 11:55 pm
Room: Moderated Discussions
Linus Torvalds (torvalds@osdl.org) on 10/23/06 wrote:
---------------------------
>Rob Thorpe (rthorpe@realworldtech.com) on 10/23/06 wrote:
>>
>>1. Allocations are done with memory barriers
>
>The thing is, allocation are the easiest case by far,
>and doing memory barriers there is free or at least cheap
>enough to generally not matter.
This is very good news. If the write barrier is cheap, perhaps there isn't a problem.
>The problem with multi-threaded is all the other
>accesses. You should look at those, not at allocations.
That is true of course if we are looking at multi-threaded programming in general. Our worry in this particular case is that safe languages require a memory barrier even for objects which are not shared between threads in order to ensure language safety. This is a specific problem, which admitteldy on its own may be not that severe.
>The problem with write barriers is not the writing side,
>it's the reading side. A write barrier generally
>always has to be paired with a read barrier, and that
>can be very expensive indeed. Much more so than any write
>barrier, at least, since unlike write barriers (which can
>usually be done just as rules in the write-queue), a read
>barrier is a big barrier to any OoO engine too.
>
>However, the reason read barriers aren't necessary for
>the special case of allocation is that most architectures
>have other consistency guarantees, and notably there is
>almost always an "implied barrier" due to the dependency
>between reading the address and reading anything that it
>points to. I say "almost always", because some architectures
>will actually break even that dependency, even though it
>might sound impossible (alpha, for example, does that,
>possibly MIPS too).
Does it really ? So far I have assumed that we don't need read barriers. This really would put a new and terrible spin on things. So the write barrier still doesn't guarantee what the other thread sees unless the second thread uses a read barrier ??? So this code could assert !?!:
I will have to think about what this means ...
---------------------------
>Rob Thorpe (rthorpe@realworldtech.com) on 10/23/06 wrote:
>>
>>1. Allocations are done with memory barriers
>
>The thing is, allocation are the easiest case by far,
>and doing memory barriers there is free or at least cheap
>enough to generally not matter.
This is very good news. If the write barrier is cheap, perhaps there isn't a problem.
>The problem with multi-threaded is all the other
>accesses. You should look at those, not at allocations.
That is true of course if we are looking at multi-threaded programming in general. Our worry in this particular case is that safe languages require a memory barrier even for objects which are not shared between threads in order to ensure language safety. This is a specific problem, which admitteldy on its own may be not that severe.
>The problem with write barriers is not the writing side,
>it's the reading side. A write barrier generally
>always has to be paired with a read barrier, and that
>can be very expensive indeed. Much more so than any write
>barrier, at least, since unlike write barriers (which can
>usually be done just as rules in the write-queue), a read
>barrier is a big barrier to any OoO engine too.
>
>However, the reason read barriers aren't necessary for
>the special case of allocation is that most architectures
>have other consistency guarantees, and notably there is
>almost always an "implied barrier" due to the dependency
>between reading the address and reading anything that it
>points to. I say "almost always", because some architectures
>will actually break even that dependency, even though it
>might sound impossible (alpha, for example, does that,
>possibly MIPS too).
Does it really ? So far I have assumed that we don't need read barriers. This really would put a new and terrible spin on things. So the write barrier still doesn't guarantee what the other thread sees unless the second thread uses a read barrier ??? So this code could assert !?!:
int a = 0, * b = null;
/* Thread 1 */
a = 1;
MB(); /* write barrier ! */
b = &a;
/* Thread 2 */
if (b)
assert( *b == 1 );
I will have to think about what this means ...