------=_Part_3581_1942468242.1433840011771
Content-Type: multipart/alternative;
 boundary="----=_Part_3582_195473786.1433840011777"

------=_Part_3582_195473786.1433840011777
Content-Type: text/plain; charset=UTF-8

Hello,

I have one question on the spec for concurrency extension.
The latest doc (N4539) defines two atomic smart pointers
atomic_{shared,weak}_ptr, while
in the original proposal (N4162/N4260) defined three:
atomic_{shared,weak,unique}_ptr.

So, where did the atomic_unique_ptr go? I'd like to know the rational
behind dropping it,
but could not find in the published papers. Is there any
document/discussion I can read on it?

# Sorry if I'm posting to a wrong group. In the case I'm very happy if I
could know a pointer to the right place for this topic.

Many Thanks,
Kazuhiro.

--

---
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_3582_195473786.1433840011777
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello,</div><div><br></div><div>I have one question o=
n the spec for concurrency extension.</div><div>The latest doc (N4539) defi=
nes two atomic smart pointers atomic_{shared,weak}_ptr, while<br></div><div=
>in the original proposal (N4162/N4260) defined three: atomic_{shared,weak,=
unique}_ptr.</div><div><br></div><div>So, where did the atomic_unique_ptr g=
o? I'd like to know the rational behind dropping it,</div><div>but could no=
t find in the published papers. Is there any document/discussion I can read=
 on it?</div><div><br></div><div># Sorry if I'm posting to a wrong group. I=
n the case I'm very happy if I could know a pointer to the right place for =
this topic.<br></div><div><br></div><div>Many Thanks,</div><div>Kazuhiro.<b=
r></div><div><br></div></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_3582_195473786.1433840011777--
------=_Part_3581_1942468242.1433840011771--

.

On 09/06/15 09:53, Kazuhiro Inaba wrote:
> I have one question on the spec for concurrency extension.
> The latest doc (N4539) defines two atomic smart pointers
> atomic_{shared,weak}_ptr, while
> in the original proposal (N4162/N4260) defined three:
> atomic_{shared,weak,unique}_ptr.
>
> So, where did the atomic_unique_ptr go? I'd like to know the rational
> behind dropping it,
> but could not find in the published papers. Is there any
> document/discussion I can read on it?

atomic_unique_ptr is quite different to atomic_shared_ptr, and isn't as
useful as one might think, nor can it have the same interface as other
atomic types.

Precisely one unique_ptr instance can point to an owned object.
atomic_unique_ptr cannot therefore provide a simple load operation,
since it must transfer ownership to the returned unique_ptr.

Likewise, compare_exchange doesn't make sense: the only valid comparand
would be a null value, since any non-null value is guaranteed to be
different to the existing value. In addition, the previous comments
about load() would apply: compare_exchange loads the old value, which
would require taking ownership of the value.

The only valid operations on atomic_unique_ptr would therefore be
exchange() and a new set_if_null().

The use cases for such a type are vanishingly small. You are better off
using a mutex or other synchronization scheme.

Anthony
--
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++11 thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

--

---
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_392_964864969.1433850799096
Content-Type: multipart/alternative;
 boundary="----=_Part_393_836515486.1433850799096"

------=_Part_393_836515486.1433850799096
Content-Type: text/plain; charset=UTF-8

That's very unfortunate. I was really looking forward to atomic_unique_ptr.
In my use case, I had one thread do background work and publishing the
result via a unique_ptr, while other threads could check if the work is
done by simply checking if the pointer is null. atomic_unique_ptr would
have been very handy for such use cases.

--

---
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_393_836515486.1433850799096
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">That's very unfortunate. I was really looking forward to a=
tomic_unique_ptr. In my use case, I had one thread do background work and p=
ublishing the result via a unique_ptr, while other threads could check if t=
he work is done by simply checking if the pointer is null. atomic_unique_pt=
r would have been very handy for such use cases.</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_393_836515486.1433850799096--
------=_Part_392_964864969.1433850799096--

.

On 09/06/15 12:53, Markus Grech wrote:
> That's very unfortunate. I was really looking forward to
> atomic_unique_ptr. In my use case, I had one thread do background work
> and publishing the result via a unique_ptr, while other threads could
> check if the work is done by simply checking if the pointer is null.
> atomic_unique_ptr would have been very handy for such use cases.

If only one thread is publishing the data then you don't need
atomic_unique_ptr for that. Use a plain unique_ptr and atomic<bool> as a
done flag. The producer stores the pointer and sets the flag. The other
threads can read the flag, and if it is true then they can read the pointer.

Or, use std::future<std::unique_ptr<T>> and the corresponding std::promise.

Anthony
--
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++11 thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

--

---
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_5382_1978188906.1433945921944
Content-Type: multipart/alternative;
 boundary="----=_Part_5383_79120288.1433945921944"

------=_Part_5383_79120288.1433945921944
Content-Type: text/plain; charset=UTF-8

Thanks for the explanation, Anthony! Now it made more sense to me.

On 09/06/15 Anthony Williams wrote:
>
> On 09/06/15 09:53, Kazuhiro Inaba wrote:
> > I have one question on the spec for concurrency extension.
> > The latest doc (N4539) defines two atomic smart pointers
> > atomic_{shared,weak}_ptr, while
> > in the original proposal (N4162/N4260) defined three:
> > atomic_{shared,weak,unique}_ptr.
> >
> > So, where did the atomic_unique_ptr go? I'd like to know the rational
> > behind dropping it,
> > but could not find in the published papers. Is there any
> > document/discussion I can read on it?
>
> atomic_unique_ptr is quite different to atomic_shared_ptr, and isn't as
> useful as one might think, nor can it have the same interface as other
> atomic types.
>
> Precisely one unique_ptr instance can point to an owned object.
> atomic_unique_ptr cannot therefore provide a simple load operation,
> since it must transfer ownership to the returned unique_ptr.
>
> Likewise, compare_exchange doesn't make sense: the only valid comparand
> would be a null value, since any non-null value is guaranteed to be
> different to the existing value. In addition, the previous comments
> about load() would apply: compare_exchange loads the old value, which
> would require taking ownership of the value.
>
> The only valid operations on atomic_unique_ptr would therefore be
> exchange() and a new set_if_null().
>
> The use cases for such a type are vanishingly small. You are better off
> using a mutex or other synchronization scheme.
>
> Anthony
> --
> Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
> just::thread C++11 thread library             http://www.stdthread.co.uk
> Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
> 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
>

--

---
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_5383_79120288.1433945921944
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the explanation, Anthony! Now it made more sens=
e to me.<br><br>On 09/06/15 Anthony Williams wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">On 09/06/15 09:53, Kazuhiro Inaba wrote:
<br>&gt; I have one question on the spec for concurrency extension.
<br>&gt; The latest doc (N4539) defines two atomic smart pointers
<br>&gt; atomic_{shared,weak}_ptr, while
<br>&gt; in the original proposal (N4162/N4260) defined three:
<br>&gt; atomic_{shared,weak,unique}_<wbr>ptr.
<br>&gt;=20
<br>&gt; So, where did the atomic_unique_ptr go? I'd like to know the ratio=
nal
<br>&gt; behind dropping it,
<br>&gt; but could not find in the published papers. Is there any
<br>&gt; document/discussion I can read on it?
<br>
<br>atomic_unique_ptr is quite different to atomic_shared_ptr, and isn't as
<br>useful as one might think, nor can it have the same interface as other
<br>atomic types.
<br>
<br>Precisely one unique_ptr instance can point to an owned object.
<br>atomic_unique_ptr cannot therefore provide a simple load operation,
<br>since it must transfer ownership to the returned unique_ptr.
<br>
<br>Likewise, compare_exchange doesn't make sense: the only valid comparand
<br>would be a null value, since any non-null value is guaranteed to be
<br>different to the existing value. In addition, the previous comments
<br>about load() would apply: compare_exchange loads the old value, which
<br>would require taking ownership of the value.
<br>
<br>The only valid operations on atomic_unique_ptr would therefore be
<br>exchange() and a new set_if_null().
<br>
<br>The use cases for such a type are vanishingly small. You are better off
<br>using a mutex or other synchronization scheme.
<br>
<br>Anthony
<br>--=20
<br>Author of C++ Concurrency in Action &nbsp; &nbsp; <a href=3D"http://www=
..stdthread.co.uk/book/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.stdthread.co.uk%=
2Fbook%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNHkNFD_k6fdkcq3HV83Azg2W_8v8g';=
return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A=
%2F%2Fwww.stdthread.co.uk%2Fbook%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNHkNF=
D_k6fdkcq3HV83Azg2W_8v8g';return true;">http://www.stdthread.co.uk/<wbr>boo=
k/</a>
<br>just::thread C++11 thread library &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; <a href=3D"http://www.stdthread.co.uk" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2F=
www.stdthread.co.uk\46sa\75D\46sntz\0751\46usg\75AFQjCNFtNeB_7bfnp2zcEgnSyn=
TWCNWYkg';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q=
\75http%3A%2F%2Fwww.stdthread.co.uk\46sa\75D\46sntz\0751\46usg\75AFQjCNFtNe=
B_7bfnp2zcEgnSynTWCNWYkg';return true;">http://www.stdthread.co.uk</a>
<br>Just Software Solutions Ltd &nbsp; &nbsp; &nbsp; <a href=3D"http://www.=
justsoftwaresolutions.co.uk" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.justsoftwar=
esolutions.co.uk\46sa\75D\46sntz\0751\46usg\75AFQjCNH6cIjR6NHNwSY6t2QE8Ji7a=
rrTmA';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75=
http%3A%2F%2Fwww.justsoftwaresolutions.co.uk\46sa\75D\46sntz\0751\46usg\75A=
FQjCNH6cIjR6NHNwSY6t2QE8Ji7arrTmA';return true;">http://www.<wbr>justsoftwa=
resolutions.co.uk</a>
<br>15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 547897=
6
<br></blockquote></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_5383_79120288.1433945921944--
------=_Part_5382_1978188906.1433945921944--

.