469,927 Members | 1,978 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,927 developers. It's quick & easy.

Re: acquire barrier for atomic reference counting

On 16 ΝΑΚ, 21:41, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
Can you clarify about atomic_global_fence_compatibility.

1.10/7 (N2521)
"An evaluation A that performs a release operation on an object M
synchronizes with an evaluation B that performs an acquire operation
on M and reads a value written by any side effect in the release
sequence headed by A."

Release operation is performed on 'obj->rc' and acquire operation is
performed on 'std::atomic_global_fence_compatibility'. So why the
former 'synchronizes with' the latter?

According to definition, release operation on
'std::atomic_global_fence_compatibility' can only 'synchronize with'
acquire operation on 'std::atomic_global_fence_compatibility'.
Imho, it's a bit senseless. I think that I miss something. Can
somebody clarify about std::atomic_global_fence_compatibility?
Dmitriy V'jukov
Jun 27 '08 #1
10 2128
On May 17, 4:07 pm, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
On 16 ΝΑΚ, 21:41, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
Can you clarify about atomic_global_fence_compatibility.
1.10/7 (N2521)
"An evaluation A that performs a release operation on an object M
synchronizes with an evaluation B that performs an acquire operation
on M and reads a value written by any side effect in the release
sequence headed by A."
Release operation is performed on 'obj->rc' and acquire operation is
performed on 'std::atomic_global_fence_compatibility'. So why the
former 'synchronizes with' the latter?

According to definition, release operation on
'std::atomic_global_fence_compatibility' can only 'synchronize with'
acquire operation on 'std::atomic_global_fence_compatibility'.
Imho, it's a bit senseless. I think that I miss something. Can
somebody clarify about std::atomic_global_fence_compatibility?
It's a global fence (see 29.3p11 in N2588). If that's not clear, then
that's a defect.

Anthony
Jun 27 '08 #2
"Dmitriy V'jukov" <dv*****@gmail.comwrites:
My current understanding is that:
1. atomic_global_fence_compatibility must have some special treatment
from language.
or
2. it's useless.
My understanding is #1: it has special treatment. Use of this variable
for a fence is equivalent to a global fence instruction.

Anthony
--
Anthony Williams | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Jun 27 '08 #3
On May 20, 6:15 pm, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
2. Acquire operation must read value in 'release-sequence' of release
operation. What value "reads" fence() function? Since fence() is RMW
atomic operation, it must "read" some value. But how can I find out
what value it reads?
Btw, this applies to atomic_fence() function in general - what value
it "reads"?
If I don't know what value it reads then I can't be sure that
something 'synchronized-with'.

Dmitriy V'jukov
Jun 27 '08 #4
On May 20, 6:20 pm, anthony....@gmail.com wrote:
"Dmitriy V'jukov" <dvyu...@gmail.comwrites:
My current understanding is that:
1. atomic_global_fence_compatibility must have some special treatment
from language.
or
2. it's useless.

My understanding is #1: it has special treatment. Use of this variable
for a fence is equivalent to a global fence instruction.
Where this 'special treatment' formally described?
29.4/11 (N2588) says only "... may be used to emulate global fences".
And 29.4/11 a *Note*.
I don't see any 'special treatment'. And according to 1.10 your
example is broken...

Dmitriy V'jukov
Jun 27 '08 #5
"Dmitriy V'jukov" <dv*****@gmail.comwrites:
On May 20, 6:15 pm, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
>2. Acquire operation must read value in 'release-sequence' of release
operation. What value "reads" fence() function? Since fence() is RMW
atomic operation, it must "read" some value. But how can I find out
what value it reads?

Btw, this applies to atomic_fence() function in general - what value
it "reads"?
You apply a fence on a specific variable, and it "reads" one of the
values written to the variable by some thread. A fence is a RMW
operation that writes the same value back.
If I don't know what value it reads then I can't be sure that
something 'synchronized-with'.
True. Fences need to be used carefully, and in combination with other
operations.

Anthony
--
Anthony Williams | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Jun 27 '08 #6
"Dmitriy V'jukov" <dv*****@gmail.comwrites:
On May 20, 6:20 pm, anthony....@gmail.com wrote:
>"Dmitriy V'jukov" <dvyu...@gmail.comwrites:
My current understanding is that:
1. atomic_global_fence_compatibility must have some special treatment
from language.
or
2. it's useless.

My understanding is #1: it has special treatment. Use of this variable
for a fence is equivalent to a global fence instruction.

Where this 'special treatment' formally described?
29.4/11 (N2588) says only "... may be used to emulate global fences".
And 29.4/11 a *Note*.
I don't see any 'special treatment'. And according to 1.10 your
example is broken...
I've raised the issue on the LWG reflector. I'll let you know what
others say.

Anthony
--
Anthony Williams | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Jun 27 '08 #7
On May 20, 7:12 pm, anthony....@gmail.com wrote:
"Dmitriy V'jukov" <dvyu...@gmail.comwrites:
On May 20, 6:15 pm, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
2. Acquire operation must read value in 'release-sequence' of release
operation. What value "reads" fence() function? Since fence() is RMW
atomic operation, it must "read" some value. But how can I find out
what value it reads?
Btw, this applies to atomic_fence() function in general - what value
it "reads"?

You apply a fence on a specific variable, and it "reads" one of the
values written to the variable by some thread. A fence is a RMW
operation that writes the same value back.
If I don't know what value it reads then I can't be sure that
something 'synchronized-with'.

True. Fences need to be used carefully, and in combination with other
operations.

Ok. In following example I know what value fence operation will
"read". And luckily 'release sequence' is still not broken when
acquire operation executes.

void release(T* obj)
{
int rc = obj->rc.fetch_add(-1, memory_order_release) - 1;
if (0 == rc)
{
if (0 == obj->rc.fence(memory_order_acquire))
delete obj;
else
assert(false);
}
}
But let's consider Paul McKenney's motivating example from N2153
(http://www.open-std.org/jtc1/sc22/wg...07/n2153.pdf):

for (i=0; i< num_mailboxes; i++)
{
if (mailbox[i].load_raw() == my_id)
{
acquire_fence(); // Prevents speculation of memory do_work(i);
// accesses in do_work
}
}

The goal is to remove acquire fence from every load. And issue acquire
fence only when there is real work to do.

As I understand following code won't work:

for (i=0; i< num_mailboxes; i++)
{
if (mailbox[i].load(std::memory_order_relaxed) == my_id)
{
mailbox[i].fence(std::memory_order_acquire); // Prevents
speculation of memory do_work(i);
// accesses in do_work
}
}

Because 'release sequence' is just broken by relaxed load. Right?

This code will work if definition of 'synchronizes with' will be
changed from:

"An evaluation A that performs a release operation on an object M
synchronizes with an evaluation B that performs an acquire operation
on M and reads a value written by any side effect in the release
sequence headed by A."

to:

"An evaluation A that performs a release operation on an object M
synchronizes with an evaluation B that performs an acquire operation
on M and B *or any expression sequenced before B* reads a value
written by any side effect in the release sequence headed by A."

What do you think?

Dmitriy V'jukov
Jun 27 '08 #8
"Dmitriy V'jukov" <dv*****@gmail.comwrites:
Ok. In following example I know what value fence operation will
"read". And luckily 'release sequence' is still not broken when
acquire operation executes.

void release(T* obj)
{
int rc = obj->rc.fetch_add(-1, memory_order_release) - 1;
if (0 == rc)
{
if (0 == obj->rc.fence(memory_order_acquire))
delete obj;
else
assert(false);
}
}
I'm happy that this example is fine.
But let's consider Paul McKenney's motivating example from N2153
(http://www.open-std.org/jtc1/sc22/wg...07/n2153.pdf):

for (i=0; i< num_mailboxes; i++)
{
if (mailbox[i].load_raw() == my_id)
{
acquire_fence(); // Prevents speculation of memory do_work(i);
// accesses in do_work
}
}

The goal is to remove acquire fence from every load. And issue acquire
fence only when there is real work to do.

As I understand following code won't work:

for (i=0; i< num_mailboxes; i++)
{
if (mailbox[i].load(std::memory_order_relaxed) == my_id)
{
mailbox[i].fence(std::memory_order_acquire); // Prevents
speculation of memory do_work(i);
// accesses in do_work
}
}

Because 'release sequence' is just broken by relaxed load. Right?
The relaxed load is just that: a load. It therefore does not feature
in the "modification sequence" of mailbox[i], and does not break the
release sequence. Therefore the store/release that writes mailbox[i]
can still synchronize-with the fence.

I think this example does in fact work.
This code will work if definition of 'synchronizes with' will be
changed from:

"An evaluation A that performs a release operation on an object M
synchronizes with an evaluation B that performs an acquire operation
on M and reads a value written by any side effect in the release
sequence headed by A."

to:

"An evaluation A that performs a release operation on an object M
synchronizes with an evaluation B that performs an acquire operation
on M and B *or any expression sequenced before B* reads a value
written by any side effect in the release sequence headed by A."

What do you think?
I think that is unnecessary. A relaxed load doesn't interfere with the
release sequence or the modification sequence, and if the relaxed load
sees the value, a subsequent acquire on the same thread can only see
that value or a later value (1.10p10 in N2588).

Anthony
--
Anthony Williams | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Jun 27 '08 #9
On May 20, 8:35 pm, anthony....@gmail.com wrote:
Because 'release sequence' is just broken by relaxed load. Right?

The relaxed load is just that: a load. It therefore does not feature
in the "modification sequence" of mailbox[i], and does not break the
release sequence. Therefore the store/release that writes mailbox[i]
can still synchronize-with the fence.

Yikes! You are right!

I think this example does in fact work.

Ok. Things start clearing up :)

This code will work if definition of 'synchronizes with' will be
changed from:
"An evaluation A that performs a release operation on an object M
synchronizes with an evaluation B that performs an acquire operation
on M and reads a value written by any side effect in the release
sequence headed by A."
to:
"An evaluation A that performs a release operation on an object M
synchronizes with an evaluation B that performs an acquire operation
on M and B *or any expression sequenced before B* reads a value
written by any side effect in the release sequence headed by A."
What do you think?

I think that is unnecessary. A relaxed load doesn't interfere with the
release sequence or the modification sequence, and if the relaxed load
sees the value, a subsequent acquire on the same thread can only see
that value or a later value (1.10p10 in N2588).

Yes, it already works figuratively this way:
1. Load function 'reads the value'
2. Subsequent acquire fence 'performs an acquire operation'
Dmitriy V'jukov
Jun 27 '08 #10
an*********@gmail.com writes:
"Dmitriy V'jukov" <dv*****@gmail.comwrites:
>On May 20, 6:20 pm, anthony....@gmail.com wrote:
>>"Dmitriy V'jukov" <dvyu...@gmail.comwrites:
My current understanding is that:
1. atomic_global_fence_compatibility must have some special treatment
from language.
or
2. it's useless.

My understanding is #1: it has special treatment. Use of this variable
for a fence is equivalent to a global fence instruction.

Where this 'special treatment' formally described?
29.4/11 (N2588) says only "... may be used to emulate global fences".
And 29.4/11 a *Note*.
I don't see any 'special treatment'. And according to 1.10 your
example is broken...

I've raised the issue on the LWG reflector. I'll let you know what
others say.
Fences are due to be discussed at the committee meeting in June, so
everything may change, but at the moment
atomic_global_fence_compatibility is *not* afforded any special
treatment, so my use of it in the example was incorrect.

Anthony
--
Anthony Williams | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Jun 27 '08 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Elbert Lev | last post: by
8 posts views Thread by Glenn Kasten | last post: by
1 post views Thread by Tony Johansson | last post: by
31 posts views Thread by William Stacey [MVP] | last post: by
4 posts views Thread by aaronfude | last post: by
3 posts views Thread by Ole Nielsby | last post: by
1 post views Thread by oec.deepak | last post: by
11 posts views Thread by Jon Harrop | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.