Copy / Assignment of dash::Atomic

[fuchsto]

Question on dash::Atomic:

Why is the copy constructor deleted, but assignment is not?

• operator=(T) is deleted
• operator=(const self_t &) is implicitly defaulted

That can't be right
When I explicitly delete assignment, tests don't compile

Also, the constructor Atomic(T) is not marked explicit, so it's an implicit conversion constructor
What's the intended semantics here?

The current implementation contradicts the documentation in dash/include/dash/Atomic.h

[fuchsto]

For now, I added

self_t & operator=(const self_t & other) = default;

But assignment is still explicitly deleted, so this is not well-defined.

[fmoessbauer]

Yes, that should be fixed. From the type-safety side it would be best to disable all forms of assignment, because the member is always set by DART using memory copy. But if all assignments are disabled, the dash algorithms like dash::fill will not work anymore, as they use local assignment internally.

AFAIK we have the following options:

• make assignment private and use friend
• allow assignment and live with *(array.lbegin()) = 5 being possible

[fuchsto]

It's actually to be expected that dash::fill would not work for dash::Atomic<T> containers value types.

Similarily, you can;t use std::fill for an STL std::vector<std::atomic<T>>.
So a container cannot be "filled" with atomics, they need to exist already. You would have to use emplace_back (not implying you should, though).

In general terms: semantics have priority over algorithm convenience. Especially for non-trivial types like atomics. Assignment and conversion (oh my!) should not be allowed.

We might be able to make dash::for_each work to initialize a dash::Array<dash::Atomic<T>> with a function that uses elem.store instead of assignment.

[fmoessbauer]

With some knowledge gained the last couple of month, I want to re-think the topic:

It's actually to be expected that dash::fill would not work for dash::Atomic<T> containers value types.

No, not really as the assignment operator of std::Atomic (T operator=( T desired )) is defined. This atomically replaces the value. Of course, that is not possible in DASH, as we have to use DART for atomically replacing the value at an DART address. However our implementation should provide a similar interface if possible.

Similarily, you can;t use std::fill for an STL std::vector<std::atomic<T>>.
So a container cannot be "filled" with atomics, they need to exist already.

That is only partially correct: std::fill works for atomic types, as it assigns the values. The only thing necessary to use std::vector<std::atomic<T>> is to construct the atomics in place, as they cannot be copied.

We might be able to make dash::for_each work to initialize a dash::Array<dash::Atomic<T>> with a function that uses elem.store instead of assignment.

Yes, and the way I intend to do this is by using iterator traits. With the stuff in PR #310 and #300 , it will be easy to switch the algorithm to use an non-localized version (working on the local part, but using DART) .

After merging these PRs, I will take care of fixing the implementation.

[fuchsto]

That is only partially correct: std::fill works for atomic types, as it assigns the values. The only thing
necessary to use std::vector<std::atomic> is to construct the atomics in place, as they cannot be
copied.

Yes, and as fill does not provide emplace the elements have to exist, that's what I wrote.
For example, std::filling an std::array<std::atomic<T>> would work as the elements are pre-initialized.
Where did I go wrong in my statement?

On using iterator traits to dictate the behavior of dash::for_each:
Obviously, iterator traits specify ... well, traits (properties) of an iterator type.
As iterators are exclusively about iteration, these traits can only possibly affect iteration semantics.

So if I got your point, you want to specialize dash::for_each for a new iterator trait, say "emplace_iterator_tag".
That already sounds really fishy, you must admit.
Iterators aren't even aware of const'ness of their referenced values, but now they even specify their assignment operations? I find it hard to rationalize.

First, what's the category of this trait? We would have to invent one. That is, there will be a new category of iterator properties which is orthogonal to all traits that actually specify iterator properties.
Perhaps my cold sweat is just the autism, but ...

Then: iterators, hence the name, are a concept for iteration. That's what the iterator tags in the STL all are about: to specify / restrict positioning in the iteration space.
Also, assuming we implement it like this, we would hide value semantics from the user. Values are assigned with different operation semantics and there is no way of knowing, apart from enable_ifing every interface.
Lastly, it would not work with STL algorithms as these don't respect non-STL traits.

But perhaps I got your point wrong in the first place.

PS: If the STL consistently does not allow a specific usage (like removing and returning an element in a single operation or turning an address into an atomic reference in mid-air), this is a strong indication that there are reasons not to do it.
It might be irrelevant reasons, but I think we should analyze this some more until we are confidently aware of them.