http://groups.google.com/group/comp.programming.threads?hl=en
comp.programming.threads@googlegroups.com
Today's topics:
* removing store/load in Peterson's algorithm? - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/6a7e7620b0cd85eb?hl=en
* Weird unlocked behaviour? - 4 messages, 3 authors
http://groups.google.com/group/comp.programming.threads/t/62e5cced42865212?hl=en
* locking patterns - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/1f9c0cb67051db7d?hl=en
==============================================================================
TOPIC: removing store/load in Peterson's algorithm?
http://groups.google.com/group/comp.programming.threads/t/6a7e7620b0cd85eb?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Dec 21 2009 11:51 pm
From: Dmitriy Vyukov
On Dec 21, 10:23 pm, "James" <n...@spam.invalid> wrote:
> > > The test code does not. I was just testing the performance in a single
> > > threaded loop. It seems like this should model best non-contended case
> > > scenario. If you are indeed right that:
>
> > > STORE16(&state, 1);
> > > LOAD32(&state)
>
> > > is substitution for:
>
> > > STORE32(&state1, 1);
> > > MFENCE;
> > > LOAD32(&state2);
> > I did not mean that it's a substitution. I meant that if you test one
> > variant against another then you must test against:
> > STORE32(&state1, 1);
> > MFENCE;
> > LOAD32(&state2);
> > and not against:
> > STORE32(&state1, 1);
> > LOAD32(&state2);
>
> In the relevant portion of the test code:
>
> #if defined (USE_MFENCE)
>
> for (unsigned int i = 0; i < 1000000000; ++i)
> {
> a = 1;
> _asm { MFENCE };
> unsigned int volatile c = b;
> }
>
> #else
>
> for (unsigned int i = 0; i < 1000000000; ++i)
> {
> unsigned short* volatile p16 = (unsigned short*)&a;
> *p16 = 1;
> unsigned int volatile c = a;
> }
>
>
No comments:
Post a Comment