comp.programming.threads - 13 new messages in 3 topics - digest

comp.programming.threads
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? - 11 messages, 2 authors
http://groups.google.com/group/comp.programming.threads/t/6a7e7620b0cd85eb?hl=en
* a lock-based proxy collector? - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/3b70d0ead8e62e15?hl=en
* Async break while ( std::getline( std::cin, str ) ) loop - 1 messages, 1
author
http://groups.google.com/group/comp.programming.threads/t/8038a2158728db79?hl=en

==============================================================================
TOPIC: removing store/load in Peterson's algorithm?
http://groups.google.com/group/comp.programming.threads/t/6a7e7620b0cd85eb?hl=en
==============================================================================

== 1 of 11 ==
Date: Sun, Dec 20 2009 11:44 pm
From: Dmitriy Vyukov

On 20 дек, 23:07, "James" <n...@spam.invalid> wrote:

> If each thread had it's own Petersons lock with collocation trick, could you
> get a read-write lock without using explicit membars on TSO mem-model?

That's impossible. Strong contention resolution can't be cheap by its
nature. Period.
It requires expensive membar or something equivalent. If you do not
write it explicitly then processor will emit it implicitly (or your
mutex just won't work). In either case strong synchronization won't be
cheap.

To the best of my knowledge the only way to remove that nasty
#StoreLoad is to employ asymmetric synchronization:
http://home.comcast.net/~pjbishop/Dave/Asymmetric-Dekker-Synchronization.txt
http://groups.google.ru/group/lock-free/browse_frm/thread/1efdc652571c6137
http://groups.google.ru/group/lock-free/browse_frm/thread/31f07e15df7f988e
http://groups.google.ru/group/comp.programming.threads/msg/3406433437fffe1e

--
Dmitriy V'jukov

== 2 of 11 ==
Date: Mon, Dec 21 2009 7:08 am
From: "James"

"Dmitriy Vyukov" <dvyukov@gmail.com> wrote in message
news:e26e42a6-ce73-4e9f-be3a-32b5d3805bf0@b2g2000yqi.googlegroups.com...
> > news:7cb11d95-40f0-442f-8857-7f7bb01fca2b@j4g2000yqe.googlegroups.com...
> > On Dec 18, 5:40 pm, "James" <n...@spam.invalid> wrote:
[...]

> > Is the collocation trick equal to a store/load wrt other variables?

> STORE16(&state, 1);
> LOAD32(&state)

> is substitution for:

> STORE32(&state1, 1);
> MFENCE;
> LOAD32(&state2);

> I do not remember as to whether that was me who measured this or not,
> but AFAIR above variants have equal performance on Intel x86, i.e.
> processor effectively emits MFENCE when it detects RAW conflict (read-
> after-write) with mismatching operand addresses/sizes.

Here is a very simple little test I wrote for MSVC++:

#include <cstdio>

#define USE_MFENCE

int main()
{
unsigned int volatile a = 0xFFFF;
unsigned int volatile b = 0;

#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;
}