Connecting Tech Pros Worldwide Forums | Help | Site Map

Re: acquire barrier for atomic reference counting

Dmitriy V'jukov
Guest
 
Posts: n/a
#1: Jun 27 '08
On 16 อมส, 21:41, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
Quote:
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

anthony.ajw@gmail.com
Guest
 
Posts: n/a
#2: Jun 27 '08

re: Re: acquire barrier for atomic reference counting


On May 17, 4:07 pm, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
Quote:
On 16 อมส, 21:41, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
>
Quote:
Can you clarify about atomic_global_fence_compatibility.
>
Quote:
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."
>
Quote:
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
anthony.ajw@gmail.com
Guest
 
Posts: n/a
#3: Jun 27 '08

re: Re: acquire barrier for atomic reference counting


"Dmitriy V'jukov" <dvyukov@gmail.comwrites:
Quote:
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
Dmitriy V'jukov
Guest
 
Posts: n/a
#4: Jun 27 '08

re: Re: acquire barrier for atomic reference counting


On May 20, 6:15 pm, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
Quote:
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
Dmitriy V'jukov
Guest
 
Posts: n/a
#5: Jun 27 '08

re: Re: acquire barrier for atomic reference counting


On May 20, 6:20 pm, anthony....@gmail.com wrote:
Quote:
"Dmitriy V'jukov" <dvyu...@gmail.comwrites:
Quote:
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
anthony.ajw@gmail.com
Guest
 
Posts: n/a
#6: Jun 27 '08

re: Re: acquire barrier for atomic reference counting


"Dmitriy V'jukov" <dvyukov@gmail.comwrites:
Quote:
On May 20, 6:15 pm, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
>
Quote:
>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.
Quote:
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
anthony.ajw@gmail.com
Guest
 
Posts: n/a
#7: Jun 27 '08

re: Re: acquire barrier for atomic reference counting


"Dmitriy V'jukov" <dvyukov@gmail.comwrites:
Quote:
On May 20, 6:20 pm, anthony....@gmail.com wrote:
Quote:
>"Dmitriy V'jukov" <dvyu...@gmail.comwrites:
Quote:
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
Dmitriy V'jukov
Guest
 
Posts: n/a
#8: Jun 27 '08

re: Re: acquire barrier for atomic reference counting


On May 20, 7:12 pm, anthony....@gmail.com wrote:
Quote:
"Dmitriy V'jukov" <dvyu...@gmail.comwrites:
Quote:
On May 20, 6:15 pm, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
>
Quote:
Quote:
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?
>
Quote:
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.
>
Quote:
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
anthony.ajw@gmail.com
Guest
 
Posts: n/a
#9: Jun 27 '08

re: Re: acquire barrier for atomic reference counting


"Dmitriy V'jukov" <dvyukov@gmail.comwrites:
Quote:
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.
Quote:
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.
Quote:
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
Dmitriy V'jukov
Guest
 
Posts: n/a
#10: Jun 27 '08

re: Re: acquire barrier for atomic reference counting


On May 20, 8:35 pm, anthony....@gmail.com wrote:
Quote:
Quote:
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!

Quote:
I think this example does in fact work.

Ok. Things start clearing up :)

Quote:
Quote:
This code will work if definition of 'synchronizes with' will be
changed from:
>
Quote:
"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."
>
Quote:
to:
>
Quote:
"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."
>
Quote:
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
anthony.ajw@gmail.com
Guest
 
Posts: n/a
#11: Jun 27 '08

re: Re: acquire barrier for atomic reference counting


anthony.ajw@gmail.com writes:
Quote:
"Dmitriy V'jukov" <dvyukov@gmail.comwrites:
>
Quote:
>On May 20, 6:20 pm, anthony....@gmail.com wrote:
Quote:
>>"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
Closed Thread