I've been getting a little down to grips with the new Visual Studio native Concurrency runtime (ConcRT). Is it just an oversight, or is there a valid reason that no cross-thread movement of data has movement semantics? They're all copy semantics. You can't move into a concurrent queue, you can't move with asend, etc. You can't even move construct concurrent queues.
I don't know this specific framework, but generally for inter thread queues you must have copy semantics.
Imagine I create an object, take a reference/pointer to it then move it to the queue. Then the other thread moves it out of the queue. Then both threads can access it at the same time.
I think that in the general case it is only necessary to have copy on ever of add or remove, not both (ie only one copy needed). e.g. copy-in move-out, but this would be semantically the same as copy-in copy-out.
There are a number of areas where rvalue support could enhance ConcRT, agents and the PPL. Like any big software project, when you are building features that rely on other new features, there always some risk in being able to deliver everything at once.
PPL was a major step forward but we never said it was "done". :-)
If you have particular suggestions where ConcRT, PPL, or the Agents library should support move semantics, please open up a suggestion in connect.microsoft.com.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With