------=_Part_2613_3508153.1443602774334
Content-Type: multipart/alternative;
 boundary="----=_Part_2614_462091708.1443602774334"

------=_Part_2614_462091708.1443602774334
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,

As small addition to the C++ memory model, it would be nice to have a way=
=20
to request compiler-only synchronization for all atomic<> ops, like the one=
=20
imposed by atomic_signal_fence. Either as a memory_order_signal flag to be=
=20
'or'ed to the other memory_order_* flags or a full family of=20
memory_order_signal_{relaxed,release,acquire,acq_rel,seq_cst}.

These new memory model flags would use the same wording as for=20
atomic_signal_fence:

"E=EF=AC=80ects: memory_order_signal_* is equivalent to the corresponding m=
emory_order_*,  except that the resulting ordering constraints =20
are established only between a thread and a signal handler executed in the =
same thread."
"Note: compiler optimizations and reorderings of loads and stores are inhib=
ited in the same way as with memory_order_* operations,=20
but the hardware fence instructions that memory_order_* would have inserted=
 are not emitted."


The expectation is that for x86, for example, memory_order_signal RMW=20
operations would map to the the underlying atomic RMW *without* the lock=20
prefix.

My use case is synchronization between threads pinned to the same core.

-- gpd

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_2614_462091708.1443602774334
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<br><br>As small addition to the C++ memory model, =
it would be nice to have a way to request compiler-only synchronization for=
 all atomic&lt;&gt; ops, like the one imposed by atomic_signal_fence. Eithe=
r as a memory_order_signal flag to be &#39;or&#39;ed to the other memory_or=
der_* flags or a full family of memory_order_signal_{relaxed,release,acquir=
e,acq_rel,seq_cst}.<br><br>These new memory model flags would use the same =
wording as for atomic_signal_fence:<br><br><pre class=3D"bz_comment_text"><=
span style=3D"font-family: arial,sans-serif;">&quot;E=EF=AC=80ects: memory_=
order_signal_* is equivalent to the corresponding memory_order_*,  except t=
hat the resulting ordering constraints  <br>are established only between a =
thread and a signal handler executed in the same thread.&quot;
<br></span><span style=3D"font-family: arial,sans-serif;"><span style=3D"fo=
nt-family: arial,sans-serif;"><span style=3D"font-family: arial,sans-serif;=
">&quot;Note: compiler optimizations and reorderings of loads and stores ar=
e inhibited in the same way as with memory_order_* operations, </span></spa=
n></span><span style=3D"font-family: arial,sans-serif;"><br></span><span st=
yle=3D"font-family: arial,sans-serif;">but the hardware fence instructions =
that memory_order_* would have inserted are not emitted.</span>&quot;<br></=
pre><br>The expectation is that for x86, for example, memory_order_signal R=
MW operations would map to the the underlying atomic RMW *without* the lock=
 prefix.<br><br>My use case is synchronization between threads pinned to th=
e same core.<br><br>-- gpd<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2614_462091708.1443602774334--
------=_Part_2613_3508153.1443602774334--

.

Hi Giovanni,

2015-09-30 10:46 GMT+02:00 Giovanni Piero Deretta <gpderetta@gmail.com>:
> "E=EF=AC=80ects: memory_order_signal_* is equivalent to the corresponding
> memory_order_*,  except that the resulting ordering constraints
> are established only between a thread and a signal handler executed in th=
e
> same thread."

How would this be different from using memory_order_relaxed?

--=20
Ed Schouten <ed@nuxi.nl>
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_1260_427831079.1443625086888
Content-Type: multipart/alternative;
 boundary="----=_Part_1261_1203722531.1443625086889"

------=_Part_1261_1203722531.1443625086889
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, September 30, 2015 at 3:17:29 PM UTC+1, Ed Schouten wrote:
>
> Hi Giovanni,=20
>
> 2015-09-30 10:46 GMT+02:00 Giovanni Piero Deretta <gpde...@gmail.com=20
> <javascript:>>:=20
> > "E=EF=AC=80ects: memory_order_signal_* is equivalent to the correspondi=
ng=20
> > memory_order_*,  except that the resulting ordering constraints=20
> > are established only between a thread and a signal handler executed in=
=20
> the=20
> > same thread."=20
>
> How would this be different from using memory_order_relaxed?=20
>

Memory order relaxed guarantees atomicity of RMW across threads, even=20
running on other cpus. memory_order_signal would only guarantee atomicity=
=20
with RMW done in a thread and a signal handler running on that thread.=20
Conversely memory_order_relaxed allows almost complete freedom to reorder=
=20
accesses to the compiler, while a memory_order_signal_seq_cst would not.

In fact the "proposed wording" I wrote are not enough as they only deal=20
with synchronisation, but something must be said about atomicity (probably=
=20
saying that concurrent writes or mixed read/writes accesses where at least=
=20
one of them is memory order signal is a data race).

-- gpd

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1261_1203722531.1443625086889
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, September 30, 2015 at 3:17:29 PM UTC+1, Ed S=
chouten wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi Giovanni,
<br>
<br>2015-09-30 10:46 GMT+02:00 Giovanni Piero Deretta &lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"DjGdyPtLCgAJ" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclic=
k=3D"this.href=3D&#39;javascript:&#39;;return true;">gpde...@gmail.com</a>&=
gt;:
<br>&gt; &quot;E=EF=AC=80ects: memory_order_signal_* is equivalent to the c=
orresponding
<br>&gt; memory_order_*, =C2=A0except that the resulting ordering constrain=
ts
<br>&gt; are established only between a thread and a signal handler execute=
d in the
<br>&gt; same thread.&quot;
<br>
<br>How would this be different from using memory_order_relaxed?
<br></blockquote><div><br>Memory order relaxed guarantees atomicity of RMW =
across threads, even running on other cpus. memory_order_signal would only =
guarantee atomicity with RMW done in a thread and a signal handler running =
on that thread. Conversely memory_order_relaxed allows almost complete free=
dom to reorder accesses to the compiler, while a memory_order_signal_seq_cs=
t would not.<br><br>In fact the &quot;proposed wording&quot; I wrote are no=
t enough as they only deal with synchronisation, but something must be said=
 about atomicity (probably saying that concurrent writes or mixed read/writ=
es accesses where at least one of them is memory order signal is a data rac=
e).<br></div><br>-- gpd<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1261_1203722531.1443625086889--
------=_Part_1260_427831079.1443625086888--

.

On 30.09.2015 11:46, Giovanni Piero Deretta wrote:
> Hi all,
>
> As small addition to the C++ memory model, it would be nice to have a
> way to request compiler-only synchronization for all atomic<> ops, like
> the one imposed by atomic_signal_fence. Either as a memory_order_signal
> flag to be 'or'ed to the other memory_order_* flags or a full family of
> memory_order_signal_{relaxed,release,acquire,acq_rel,seq_cst}.
>
> These new memory model flags would use the same wording as for
> atomic_signal_fence:
>
> "E=EF=AC=80ects: memory_order_signal_* is equivalent to the corresponding
> memory_order_*, except that the resulting ordering constraints
> are established only between a thread and a signal handler executed in
> the same thread."
> "Note: compiler optimizations and reorderings of loads and stores are
> inhibited in the same way as with memory_order_* operations,
> but the hardware fence instructions that memory_order_* would have
> inserted are not emitted."
>
>
> The expectation is that for x86, for example, memory_order_signal RMW
> operations would map to the the underlying atomic RMW *without* the lock
> prefix.
>
> My use case is synchronization between threads pinned to the same core.

I think, what you propose is very close to marking a regular variable=20
volatile. It doesn't guarantee atomicity wrt signal handlers in all=20
cases, but the enhanced atomic<> as you propose it won't be able to=20
provide any stronger guarantees. In particular, I'm thinking about the=20
case when atomic<> has to emulate atomicity with a lock pool. In this=20
case operations on the atomic value are not actually atomic and a signal=20
handler can be invoked in the middle of an operation.

If atomic<> is lock-free (i.e. natively supported by the hardware), then=20
I see no reason for the compiler to make volatile accesses to the same=20
type non-atomic (again, in the scope of a single thread).

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_7405_1200696753.1443629602075
Content-Type: multipart/alternative;
 boundary="----=_Part_7406_1835166833.1443629602076"

------=_Part_7406_1835166833.1443629602076
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, September 30, 2015 at 4:15:43 PM UTC+1, Andrey Semashev wrote=
:
>
> On 30.09.2015 11:46, Giovanni Piero Deretta wrote:=20
> > Hi all,=20
> >=20
> > As small addition to the C++ memory model, it would be nice to have a=
=20
> > way to request compiler-only synchronization for all atomic<> ops, like=
=20
> > the one imposed by atomic_signal_fence. Either as a memory_order_signal=
=20
> > flag to be 'or'ed to the other memory_order_* flags or a full family of=
=20
> > memory_order_signal_{relaxed,release,acquire,acq_rel,seq_cst}.=20
> >=20
> > These new memory model flags would use the same wording as for=20
> > atomic_signal_fence:=20
> >=20
> > "E=EF=AC=80ects: memory_order_signal_* is equivalent to the correspondi=
ng=20
> > memory_order_*, except that the resulting ordering constraints=20
> > are established only between a thread and a signal handler executed in=
=20
> > the same thread."=20
> > "Note: compiler optimizations and reorderings of loads and stores are=
=20
> > inhibited in the same way as with memory_order_* operations,=20
> > but the hardware fence instructions that memory_order_* would have=20
> > inserted are not emitted."=20
> >=20
> >=20
> > The expectation is that for x86, for example, memory_order_signal RMW=
=20
> > operations would map to the the underlying atomic RMW *without* the loc=
k=20
> > prefix.=20
> >=20
> > My use case is synchronization between threads pinned to the same core.=
=20
>
> I think, what you propose is very close to marking a regular variable=20
> volatile. It doesn't guarantee atomicity wrt signal handlers in all=20
> cases, but the enhanced atomic<> as you propose it won't be able to=20
> provide any stronger guarantees. In particular, I'm thinking about the=20
> case when atomic<> has to emulate atomicity with a lock pool. In this=20
> case operations on the atomic value are not actually atomic and a signal=
=20
> handler can be invoked in the middle of an operation.=20
>
> If atomic<> is lock-free (i.e. natively supported by the hardware), then=
=20
> I see no reason for the compiler to make volatile accesses to the same=20
> type non-atomic (again, in the scope of a single thread).=20
>
>
volatile load and stores are very likely already atomic, yes, but what I=20
need is compare_exchange, exchange and friends to be atomic as well, but=20
only with regard to signal handlers. Note that this is a weaker guarantee=
=20
than normal accesses, that, on some architectures can be implemented with=
=20
significantly less expensive code sequences.

Of course if the atomic is not lock free, you can easily deadlock, but then=
=20
again that is the cae case even with the existing atomic memory ordering.

I could get the same functionality by writing inline asm, but I would=20
prefer a standard implementation. As we already have atomic_signal_fence,=
=20
the need has already been recognised.

-- gpd
=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_7406_1835166833.1443629602076
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, September 30, 2015 at 4:15:43 PM UTC+1, Andrey Semashev wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">On 30.09.2015 11:46, Giovanni=
 Piero Deretta wrote:
<br>&gt; Hi all,
<br>&gt;
<br>&gt; As small addition to the C++ memory model, it would be nice to hav=
e a
<br>&gt; way to request compiler-only synchronization for all atomic&lt;&gt=
; ops, like
<br>&gt; the one imposed by atomic_signal_fence. Either as a memory_order_s=
ignal
<br>&gt; flag to be &#39;or&#39;ed to the other memory_order_* flags or a f=
ull family of
<br>&gt; memory_order_signal_{relaxed,<wbr>release,acquire,acq_rel,seq_<wbr=
>cst}.
<br>&gt;
<br>&gt; These new memory model flags would use the same wording as for
<br>&gt; atomic_signal_fence:
<br>&gt;
<br>&gt; &quot;E=EF=AC=80ects: memory_order_signal_* is equivalent to the c=
orresponding
<br>&gt; memory_order_*, except that the resulting ordering constraints
<br>&gt; are established only between a thread and a signal handler execute=
d in
<br>&gt; the same thread.&quot;
<br>&gt; &quot;Note: compiler optimizations and reorderings of loads and st=
ores are
<br>&gt; inhibited in the same way as with memory_order_* operations,
<br>&gt; but the hardware fence instructions that memory_order_* would have
<br>&gt; inserted are not emitted.&quot;
<br>&gt;
<br>&gt;
<br>&gt; The expectation is that for x86, for example, memory_order_signal =
RMW
<br>&gt; operations would map to the the underlying atomic RMW *without* th=
e lock
<br>&gt; prefix.
<br>&gt;
<br>&gt; My use case is synchronization between threads pinned to the same =
core.
<br>
<br>I think, what you propose is very close to marking a regular variable=
=20
<br>volatile. It doesn&#39;t guarantee atomicity wrt signal handlers in all=
=20
<br>cases, but the enhanced atomic&lt;&gt; as you propose it won&#39;t be a=
ble to=20
<br>provide any stronger guarantees. In particular, I&#39;m thinking about =
the=20
<br>case when atomic&lt;&gt; has to emulate atomicity with a lock pool. In =
this=20
<br>case operations on the atomic value are not actually atomic and a signa=
l=20
<br>handler can be invoked in the middle of an operation.
<br>
<br>If atomic&lt;&gt; is lock-free (i.e. natively supported by the hardware=
), then=20
<br>I see no reason for the compiler to make volatile accesses to the same=
=20
<br>type non-atomic (again, in the scope of a single thread).
<br>
<br></blockquote><div><br>volatile load and stores are very likely already =
atomic, yes, but what I need is compare_exchange, exchange and friends to b=
e atomic as well, but only with regard to signal handlers. Note that this i=
s a weaker guarantee than normal accesses, that, on some architectures can =
be implemented with significantly less expensive code sequences.<br><br>Of =
course if the atomic is not lock free, you can easily deadlock, but then ag=
ain that is the cae case even with the existing atomic memory ordering.<br>=
<br>I could get the same functionality by writing inline asm, but I would p=
refer a standard implementation. As we already have atomic_signal_fence, th=
e need has already been recognised.<br><br>-- gpd<br>=C2=A0</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_7406_1835166833.1443629602076--
------=_Part_7405_1200696753.1443629602075--

.

On 30.09.2015 19:13, Giovanni Piero Deretta wrote:
> On Wednesday, September 30, 2015 at 4:15:43 PM UTC+1, Andrey Semashev wrote:
>
>     I think, what you propose is very close to marking a regular variable
>     volatile. It doesn't guarantee atomicity wrt signal handlers in all
>     cases, but the enhanced atomic<> as you propose it won't be able to
>     provide any stronger guarantees. In particular, I'm thinking about the
>     case when atomic<> has to emulate atomicity with a lock pool. In this
>     case operations on the atomic value are not actually atomic and a
>     signal
>     handler can be invoked in the middle of an operation.
>
>     If atomic<> is lock-free (i.e. natively supported by the hardware),
>     then
>     I see no reason for the compiler to make volatile accesses to the same
>     type non-atomic (again, in the scope of a single thread).
>
>
> volatile load and stores are very likely already atomic, yes, but what I
> need is compare_exchange, exchange and friends to be atomic as well, but
> only with regard to signal handlers. Note that this is a weaker
> guarantee than normal accesses, that, on some architectures can be
> implemented with significantly less expensive code sequences.

On some architectures there are no dedicated CAS or exchange
instructions. The atomic operations can be implemented in terms of LL/SC
pair. If you translate LL/SC to normal loads and stores with your
proposed memory model arguments then the operations won't be atomic wrt
a signal handler. If not then you don't win anything.

> I could get the same functionality by writing inline asm, but I would
> prefer a standard implementation. As we already have
> atomic_signal_fence, the need has already been recognised.

atomic_signal_fence does not constitute an operation, it simply acts as
a compiler barrier. Your proposal is significantly different as it
requires the operations to be still atomic.

If you are targeting a specific architecture that has CAS and exchange
instructions then you should probably write in asm/intrinsics or exploit
additional guarantees atomic<> de-facto provides on that architecture.
Naturally, such code won't be portable to other architectures.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_752_638018047.1443632429139
Content-Type: multipart/alternative;
 boundary="----=_Part_753_969165670.1443632429139"

------=_Part_753_969165670.1443632429139
Content-Type: text/plain; charset=UTF-8

On Wednesday, September 30, 2015 at 5:38:05 PM UTC+1, Andrey Semashev wrote:
>
> On 30.09.2015 19:13, Giovanni Piero Deretta wrote:
> > On Wednesday, September 30, 2015 at 4:15:43 PM UTC+1, Andrey Semashev
> wrote:
> >
> >     I think, what you propose is very close to marking a regular
> variable
> >     volatile. It doesn't guarantee atomicity wrt signal handlers in all
> >     cases, but the enhanced atomic<> as you propose it won't be able to
> >     provide any stronger guarantees. In particular, I'm thinking about
> the
> >     case when atomic<> has to emulate atomicity with a lock pool. In
> this
> >     case operations on the atomic value are not actually atomic and a
> >     signal
> >     handler can be invoked in the middle of an operation.
> >
> >     If atomic<> is lock-free (i.e. natively supported by the hardware),
> >     then
> >     I see no reason for the compiler to make volatile accesses to the
> same
> >     type non-atomic (again, in the scope of a single thread).
> >
> >
> > volatile load and stores are very likely already atomic, yes, but what I
> > need is compare_exchange, exchange and friends to be atomic as well, but
> > only with regard to signal handlers. Note that this is a weaker
> > guarantee than normal accesses, that, on some architectures can be
> > implemented with significantly less expensive code sequences.
>
> On some architectures there are no dedicated CAS or exchange
> instructions. The atomic operations can be implemented in terms of LL/SC
> pair. If you translate LL/SC to normal loads and stores with your
> proposed memory model arguments then the operations won't be atomic wrt
> a signal handler. If not then you don't win anything.
>
>
Mapping memory_order_signal_*  to plain memory_order_* would be a
conforming implementation although suboptimal:  I would expect at the very
least that on LL/SC architectures the signal variants could be implemented
by omitting the processor memory barriers required to implement stricter
ordering than consume.


> > I could get the same functionality by writing inline asm, but I would
> > prefer a standard implementation. As we already have
> > atomic_signal_fence, the need has already been recognised.
>
> atomic_signal_fence does not constitute an operation, it simply acts as
> a compiler barrier.


I did not say it is an operation, but it has very specific semantics that
show that the designers of the C++ memory model did acknowledge the need of
more exotic synchronization scenarios (the intended use case of
atomic_signal_fence is not really synchronization with signals).

-- gpd



--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_753_969165670.1443632429139
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, September 30, 2015 at 5:38:05 PM UTC+1, Andrey Semashev wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">On 30.09.2015 19:13, Giovanni=
 Piero Deretta wrote:
<br>&gt; On Wednesday, September 30, 2015 at 4:15:43 PM UTC+1, Andrey Semas=
hev wrote:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 I think, what you propose is very close to marking a=
 regular variable
<br>&gt; =C2=A0 =C2=A0 volatile. It doesn&#39;t guarantee atomicity wrt sig=
nal handlers in all
<br>&gt; =C2=A0 =C2=A0 cases, but the enhanced atomic&lt;&gt; as you propos=
e it won&#39;t be able to
<br>&gt; =C2=A0 =C2=A0 provide any stronger guarantees. In particular, I&#3=
9;m thinking about the
<br>&gt; =C2=A0 =C2=A0 case when atomic&lt;&gt; has to emulate atomicity wi=
th a lock pool. In this
<br>&gt; =C2=A0 =C2=A0 case operations on the atomic value are not actually=
 atomic and a
<br>&gt; =C2=A0 =C2=A0 signal
<br>&gt; =C2=A0 =C2=A0 handler can be invoked in the middle of an operation=
..
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 If atomic&lt;&gt; is lock-free (i.e. natively suppor=
ted by the hardware),
<br>&gt; =C2=A0 =C2=A0 then
<br>&gt; =C2=A0 =C2=A0 I see no reason for the compiler to make volatile ac=
cesses to the same
<br>&gt; =C2=A0 =C2=A0 type non-atomic (again, in the scope of a single thr=
ead).
<br>&gt;
<br>&gt;
<br>&gt; volatile load and stores are very likely already atomic, yes, but =
what I
<br>&gt; need is compare_exchange, exchange and friends to be atomic as wel=
l, but
<br>&gt; only with regard to signal handlers. Note that this is a weaker
<br>&gt; guarantee than normal accesses, that, on some architectures can be
<br>&gt; implemented with significantly less expensive code sequences.
<br>
<br>On some architectures there are no dedicated CAS or exchange=20
<br>instructions. The atomic operations can be implemented in terms of LL/S=
C=20
<br>pair. If you translate LL/SC to normal loads and stores with your=20
<br>proposed memory model arguments then the operations won&#39;t be atomic=
 wrt=20
<br>a signal handler. If not then you don&#39;t win anything.
<br>
<br></blockquote><div><br>Mapping memory_order_signal_*=C2=A0 to plain memo=
ry_order_* would be a conforming implementation although suboptimal:=C2=A0 =
I would expect at the very least that  on LL/SC architectures the signal va=
riants could be implemented by omitting the processor memory barriers requi=
red to implement stricter ordering than consume. <br>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">&gt; I could get the same functionality =
by writing inline asm, but I would
<br>&gt; prefer a standard implementation. As we already have
<br>&gt; atomic_signal_fence, the need has already been recognised.
<br>
<br>atomic_signal_fence does not constitute an operation, it simply acts as=
=20
<br>a compiler barrier. </blockquote><div><br>I did not say it is an operat=
ion, but it has very specific semantics that show that the designers of the=
 C++ memory model did acknowledge the need of more exotic synchronization s=
cenarios (the intended use case of atomic_signal_fence is not really synchr=
onization with signals).<br>=C2=A0<br>-- gpd<br></div><br><div>=C2=A0</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_753_969165670.1443632429139--
------=_Part_752_638018047.1443632429139--

.

On Wednesday 30 September 2015 10:00:29 Giovanni Piero Deretta wrote:
> I did not say it is an operation, but it has very specific semantics that
> show that the designers of the C++ memory model did acknowledge the need of
> more exotic synchronization scenarios (the intended use case of
> atomic_signal_fence is not really synchronization with signals).

It's not? What is it for? And why does it have "signal" in the name?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 30.09.2015 20:00, Giovanni Piero Deretta wrote:
> On Wednesday, September 30, 2015 at 5:38:05 PM UTC+1, Andrey Semashev wrote:
>
>     On 30.09.2015 19:13, Giovanni Piero Deretta wrote:
>      > On Wednesday, September 30, 2015 at 4:15:43 PM UTC+1, Andrey
>     Semashev wrote:
>      >
>      >     I think, what you propose is very close to marking a regular
>     variable
>      >     volatile. It doesn't guarantee atomicity wrt signal handlers
>     in all
>      >     cases, but the enhanced atomic<> as you propose it won't be
>     able to
>      >     provide any stronger guarantees. In particular, I'm thinking
>     about the
>      >     case when atomic<> has to emulate atomicity with a lock pool.
>     In this
>      >     case operations on the atomic value are not actually atomic
>     and a
>      >     signal
>      >     handler can be invoked in the middle of an operation.
>      >
>      >     If atomic<> is lock-free (i.e. natively supported by the
>     hardware),
>      >     then
>      >     I see no reason for the compiler to make volatile accesses to
>     the same
>      >     type non-atomic (again, in the scope of a single thread).
>      >
>      >
>      > volatile load and stores are very likely already atomic, yes, but
>     what I
>      > need is compare_exchange, exchange and friends to be atomic as
>     well, but
>      > only with regard to signal handlers. Note that this is a weaker
>      > guarantee than normal accesses, that, on some architectures can be
>      > implemented with significantly less expensive code sequences.
>
>     On some architectures there are no dedicated CAS or exchange
>     instructions. The atomic operations can be implemented in terms of
>     LL/SC
>     pair. If you translate LL/SC to normal loads and stores with your
>     proposed memory model arguments then the operations won't be atomic wrt
>     a signal handler. If not then you don't win anything.
>
>
> Mapping memory_order_signal_*  to plain memory_order_* would be a
> conforming implementation although suboptimal:  I would expect at the
> very least that on LL/SC architectures the signal variants could be
> implemented by omitting the processor memory barriers required to
> implement stricter ordering than consume.

Ok, so you could save fence instructions. That could be useful, I guess.
For the record you could achieve the same with memory_order_relaxed and
atomic_signal_fences around the operation.

>      > I could get the same functionality by writing inline asm, but I
>     would
>      > prefer a standard implementation. As we already have
>      > atomic_signal_fence, the need has already been recognised.
>
>     atomic_signal_fence does not constitute an operation, it simply acts as
>     a compiler barrier.
>
>
> I did not say it is an operation, but it has very specific semantics
> that show that the designers of the C++ memory model did acknowledge the
> need of more exotic synchronization scenarios (the intended use case of
> atomic_signal_fence is not really synchronization with signals).

The acknowledgement may be there but my point was that
atomic_signal_fence is very different from what you propose. The
function has a well-formed behavior regardless of any factors, like
lock-free property of atomic<>. Your proposed change does not have that
quality.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11401fcc6972840520ffae29
Content-Type: text/plain; charset=UTF-8

On 30 Sep 2015 7:16 pm, "Andrey Semashev" <andrey.semashev@gmail.com> wrote:
>
> On 30.09.2015 20:00, Giovanni Piero Deretta wrote:
>>
>> On Wednesday, September 30, 2015 at 5:38:05 PM UTC+1, Andrey Semashev
wrote:
>>
>>     On 30.09.2015 19:13, Giovanni Piero Deretta wrote:
>>      > On Wednesday, September 30, 2015 at 4:15:43 PM UTC+1, Andrey
>>     Semashev wrote:
>>      >
>>      >     I think, what you propose is very close to marking a regular
>>     variable
>>      >     volatile. It doesn't guarantee atomicity wrt signal handlers
>>     in all
>>      >     cases, but the enhanced atomic<> as you propose it won't be
>>     able to
>>      >     provide any stronger guarantees. In particular, I'm thinking
>>     about the
>>      >     case when atomic<> has to emulate atomicity with a lock pool.
>>     In this
>>      >     case operations on the atomic value are not actually atomic
>>     and a
>>      >     signal
>>      >     handler can be invoked in the middle of an operation.
>>      >
>>      >     If atomic<> is lock-free (i.e. natively supported by the
>>     hardware),
>>      >     then
>>      >     I see no reason for the compiler to make volatile accesses to
>>     the same
>>      >     type non-atomic (again, in the scope of a single thread).
>>      >
>>      >
>>      > volatile load and stores are very likely already atomic, yes, but
>>     what I
>>      > need is compare_exchange, exchange and friends to be atomic as
>>     well, but
>>      > only with regard to signal handlers. Note that this is a weaker
>>      > guarantee than normal accesses, that, on some architectures can be
>>      > implemented with significantly less expensive code sequences.
>>
>>     On some architectures there are no dedicated CAS or exchange
>>     instructions. The atomic operations can be implemented in terms of
>>     LL/SC
>>     pair. If you translate LL/SC to normal loads and stores with your
>>     proposed memory model arguments then the operations won't be atomic
wrt
>>     a signal handler. If not then you don't win anything.
>>
>>
>> Mapping memory_order_signal_*  to plain memory_order_* would be a
>> conforming implementation although suboptimal:  I would expect at the
>> very least that on LL/SC architectures the signal variants could be
>> implemented by omitting the processor memory barriers required to
>> implement stricter ordering than consume.
>
>
> Ok, so you could save fence instructions. That could be useful, I guess.
For the record you could achieve the same with memory_order_relaxed and
atomic_signal_fences around the operation.
>

On some architectures all RMW imply a full barrier, so relaxed doesn't
help. Even on those some architectures were relaxed is really unfenced,  an
even lighter weight implementation which doesn't need LL/SC is possible
with OS assist.

Also using explicit fences is, at least for me, always awkward.

-- gpd

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11401fcc6972840520ffae29
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On 30 Sep 2015 7:16 pm, &quot;Andrey Semashev&quot; &lt;<a href=3D"mailto:a=
ndrey.semashev@gmail.com">andrey.semashev@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On 30.09.2015 20:00, Giovanni Piero Deretta wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Wednesday, September 30, 2015 at 5:38:05 PM UTC+1, Andrey Semas=
hev wrote:<br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 On 30.09.2015 19:13, Giovanni Piero Deretta wrote:<b=
r>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt; On Wednesday, September 30, 2015 at 4:15:=
43 PM UTC+1, Andrey<br>
&gt;&gt; =C2=A0 =C2=A0 Semashev wrote:<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 =C2=A0 =C2=A0I think, what you prop=
ose is very close to marking a regular<br>
&gt;&gt; =C2=A0 =C2=A0 variable<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 =C2=A0 =C2=A0volatile. It doesn&#39=
;t guarantee atomicity wrt signal handlers<br>
&gt;&gt; =C2=A0 =C2=A0 in all<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 =C2=A0 =C2=A0cases, but the enhance=
d atomic&lt;&gt; as you propose it won&#39;t be<br>
&gt;&gt; =C2=A0 =C2=A0 able to<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 =C2=A0 =C2=A0provide any stronger g=
uarantees. In particular, I&#39;m thinking<br>
&gt;&gt; =C2=A0 =C2=A0 about the<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 =C2=A0 =C2=A0case when atomic&lt;&g=
t; has to emulate atomicity with a lock pool.<br>
&gt;&gt; =C2=A0 =C2=A0 In this<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 =C2=A0 =C2=A0case operations on the=
 atomic value are not actually atomic<br>
&gt;&gt; =C2=A0 =C2=A0 and a<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 =C2=A0 =C2=A0signal<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 =C2=A0 =C2=A0handler can be invoked=
 in the middle of an operation.<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 =C2=A0 =C2=A0If atomic&lt;&gt; is l=
ock-free (i.e. natively supported by the<br>
&gt;&gt; =C2=A0 =C2=A0 hardware),<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 =C2=A0 =C2=A0then<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 =C2=A0 =C2=A0I see no reason for th=
e compiler to make volatile accesses to<br>
&gt;&gt; =C2=A0 =C2=A0 the same<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 =C2=A0 =C2=A0type non-atomic (again=
, in the scope of a single thread).<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt; volatile load and stores are very likely =
already atomic, yes, but<br>
&gt;&gt; =C2=A0 =C2=A0 what I<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt; need is compare_exchange, exchange and fr=
iends to be atomic as<br>
&gt;&gt; =C2=A0 =C2=A0 well, but<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt; only with regard to signal handlers. Note=
 that this is a weaker<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt; guarantee than normal accesses, that, on =
some architectures can be<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt; implemented with significantly less expen=
sive code sequences.<br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 On some architectures there are no dedicated CAS or =
exchange<br>
&gt;&gt; =C2=A0 =C2=A0 instructions. The atomic operations can be implement=
ed in terms of<br>
&gt;&gt; =C2=A0 =C2=A0 LL/SC<br>
&gt;&gt; =C2=A0 =C2=A0 pair. If you translate LL/SC to normal loads and sto=
res with your<br>
&gt;&gt; =C2=A0 =C2=A0 proposed memory model arguments then the operations =
won&#39;t be atomic wrt<br>
&gt;&gt; =C2=A0 =C2=A0 a signal handler. If not then you don&#39;t win anyt=
hing.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Mapping memory_order_signal_*=C2=A0 to plain memory_order_* would =
be a<br>
&gt;&gt; conforming implementation although suboptimal:=C2=A0 I would expec=
t at the<br>
&gt;&gt; very least that on LL/SC architectures the signal variants could b=
e<br>
&gt;&gt; implemented by omitting the processor memory barriers required to<=
br>
&gt;&gt; implement stricter ordering than consume.<br>
&gt;<br>
&gt;<br>
&gt; Ok, so you could save fence instructions. That could be useful, I gues=
s. For the record you could achieve the same with memory_order_relaxed and =
atomic_signal_fences around the operation.<br>
&gt;</p>
<p dir=3D"ltr">On some architectures all RMW imply a full barrier, so relax=
ed doesn&#39;t help. Even on those some architectures were relaxed is reall=
y unfenced,=C2=A0 an even lighter weight implementation which doesn&#39;t n=
eed LL/SC is possible with OS assist.</p>
<p dir=3D"ltr">Also using explicit fences is, at least for me, always awkwa=
rd. </p>
<p dir=3D"ltr">-- gpd</p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11401fcc6972840520ffae29--

.

--001a11c333f28aff8a0520ffcd53
Content-Type: text/plain; charset=UTF-8

On 30 Sep 2015 6:16 pm, "Thiago Macieira" <thiago@macieira.org> wrote:
>
> On Wednesday 30 September 2015 10:00:29 Giovanni Piero Deretta wrote:
> > I did not say it is an operation, but it has very specific semantics
that
> > show that the designers of the C++ memory model did acknowledge the
need of
> > more exotic synchronization scenarios (the intended use case of
> > atomic_signal_fence is not really synchronization with signals).
>
> It's not? What is it for? And why does it have "signal" in the name?

It is really a compiler memory barrier. But in the C++ memory model there
is no notion of compiler reordering distinct from CPU released reordering.
The signal semantics are a brilliant trick to describe the desired property
within the confines of the C++MM.

While it can be genuinely used to synchronise with signal handlers, it is
often used in asymmetric synchronisation algorithms like some variants of
RCU, Lock reservation, work stealing, etc.

Is not a coincidence that the inventor of RCU has contributed to the
definition of C++MM.

-- gpd

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c333f28aff8a0520ffcd53
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On 30 Sep 2015 6:16 pm, &quot;Thiago Macieira&quot; &lt;<a href=3D"mailto:t=
hiago@macieira.org">thiago@macieira.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On Wednesday 30 September 2015 10:00:29 Giovanni Piero Deretta wrote:<=
br>
&gt; &gt; I did not say it is an operation, but it has very specific semant=
ics that<br>
&gt; &gt; show that the designers of the C++ memory model did acknowledge t=
he need of<br>
&gt; &gt; more exotic synchronization scenarios (the intended use case of<b=
r>
&gt; &gt; atomic_signal_fence is not really synchronization with signals).<=
br>
&gt;<br>
&gt; It&#39;s not? What is it for? And why does it have &quot;signal&quot; =
in the name?</p>
<p dir=3D"ltr">It is really a compiler memory barrier. But in the C++ memor=
y model there is no notion of compiler reordering distinct from CPU release=
d reordering. The signal semantics are a brilliant trick to describe the de=
sired property within the confines of the C++MM.</p>
<p dir=3D"ltr">While it can be genuinely used to synchronise with signal ha=
ndlers, it is often used in asymmetric synchronisation algorithms like some=
 variants of RCU, Lock reservation, work stealing, etc. </p>
<p dir=3D"ltr">Is not a coincidence that the inventor of RCU has contribute=
d to the definition of C++MM.</p>
<p dir=3D"ltr">-- gpd</p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c333f28aff8a0520ffcd53--

.