Atomic shared ptr behaviour

[Olaf van der Spek]

Suppose I've got a std::atomic<std::shared_ptr<int>> p.

If I assign a new shared_ptr to p, will destruction and deallocation of the previous pointee happen outside of the 'lock' of p or inside? Is this guaranteed by the standard?

atomic<shared_ptr<int>> p = make_shared<int>(7);

p = make_shared<int>(42);

[Anthony Williams]

On 07/02/14 14:10, Olaf van der Spek wrote:
> Suppose I've got a std::atomic<std::shared_ptr<int>> p.

Then you've got undefined behaviour. std::atomic<> requires that the
type is trivially copyable, which std::shared_ptr isn't.

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

[Daniel Krügler]

2014-02-07 15:10 GMT+01:00 Olaf van der Spek <olafv...@gmail.com>:
> Suppose I've got a std::atomic<std::shared_ptr<int>> p.

std::atomic<std::shared_ptr<int>> is not supported by the library,
because the following requirement is not satisfied:

"There is a generic class template atomic<T>. The type of the template
argument T shall be trivially
copyable (3.9)."

- Daniel

> If I assign a new shared_ptr to p, will destruction and deallocation of the
> previous pointee happen outside of the 'lock' of p or inside? Is this
> guaranteed by the standard?
>
> atomic<shared_ptr<int>> p = make_shared<int>(7);
> p = make_shared<int>(42);
>

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

[Olaf van der Spek]

On Fri, Feb 7, 2014 at 3:16 PM, Anthony Williams <antho...@gmail.com> wrote:
> On 07/02/14 14:10, Olaf van der Spek wrote:
>> Suppose I've got a std::atomic<std::shared_ptr<int>> p.
>
> Then you've got undefined behaviour. std::atomic<> requires that the
> type is trivially copyable, which std::shared_ptr isn't.

Oops. Shouldn't that cause an error? VC2013 doesn't complain.


--
Olaf

[Daniel Krügler]

This is QoI, the behaviour is undefined and doesn't require a
diagnostics. Maybe the vendor provides an extension.

- Daniel

[Casey Carter]

On Friday, February 7, 2014 8:41:07 AM UTC-6, Daniel Krügler wrote:

This is QoI, the behaviour is undefined and doesn't require a
diagnostics. Maybe the vendor provides an extension.

The requirement is from 29.5 [atomics.types.generic]/1:

There is a generic class template atomic<T>. The type of the template argument T shall be trivially

copyable (3.9). [ Note: Type arguments that are not also statically initializable may be difficult to use.
—end note ]

Which, unless I misunderstand 1.4/1, should require the implementation to diagnose programs violating the requirement as ill-formed.

[Daniel Krügler]

2014-02-07 Casey Carter <cart...@gmail.com>:

>
> On Friday, February 7, 2014 8:41:07 AM UTC-6, Daniel Krügler wrote:
>>
>>
>> This is QoI, the behaviour is undefined and doesn't require a
>> diagnostics. Maybe the vendor provides an extension.
>>
> The requirement is from 29.5 [atomics.types.generic]/1:
>
>> There is a generic class template atomic<T>. The type of the template
>> argument T shall be trivially
>> copyable (3.9). [ Note: Type arguments that are not also statically
>> initializable may be difficult to use.

>> --end note ]

>
> Which, unless I misunderstand 1.4/1, should require the implementation to
> diagnose programs violating the requirement as ill-formed.

1.4/1 holds for the complete standard, but is in particular relevant
for the core language. Beyond Clause 17 you are in "Library Land" and
you are mostly directed by 17.6.4.8 [res.on.functions], especially p1

"In certain cases (replacement functions, handler functions,
operations on types used to instantiate standard
library template components), the C++ standard library depends on
components supplied by a C++ program.
If these components do not meet their requirements, the Standard
places no requirements on the
implementation."

p2 b3 says more about this:

"In particular, the effects are undefined in the following cases:
[..]
-- for types used as template arguments when instantiating a template
component, if the operations on
the type do not implement the semantics of the applicable Requirements
subclause (17.6.3.5, 23.2,
24.2, 26.2). Operations on such types can report a failure by throwing
an exception unless otherwise
specified."

- Daniel