ISO/IEC JTC1 SC22 WG21 N4233 - 2014-10-10
Lawrence Crowl, Lawrence@Crowl.org
Chris Mysen, mysen@google.com
Introduction
Discussion
Solution
Examples
The current proposal for concurrent queues, N3533 C++ Concurrent Queues, has separate return value and output parameter for its pop operations.
Value queue::value_pop(); queue_op_status queue::try_pop(Value&); queue_op_status queue::nonblocking_pop(Value&);
This design has two consequences.
A bad status for value_pop
will result in an exception.
Use of the try_pop
and nonblocking_pop
operations
will require an Value
that is essentially default constructible.
Chandler Carruth suggested having a return value that comprised both status and value.
something<queue_op_status, Value> queue::value_pop(); something<queue_op_status, Value> queue::try_pop(); something<queue_op_status, Value> queue::nonblocking_pop();
The essential point of the design
is that something
may or may not contain a value,
and that
accessing a non-existent value results in an exception.
This design would normalize the form of the functions, move exception generation to accessing a non-existent value, and enable use of types with no default constructor as elements.
This paper proposes a mechanism to provide this combined status and value. While such a proposal could be folded into the queue proposal alone, the true value of such a mechanism would be its widespread use throughout the library, particularly in concurrent data structures where it is not technically possible to provide separate access functions for status and value. Therefore, we should either commit to or abandon such a mechanism.
The value is clearly related to the class template optional
,
as defined by
N3793 A proposal to add a utility class to represent optional objects
(Revision 5).
However, the need is almost direclty met by
the class template expected
,
as defined by
N4109 A proposal to add a utility class to represent expected monad
- Revision 1.
In our view, the weakness in the expected
proposal
is that you get either a value or an error, but not both.
In the queue proposal,
operations return a status, not an error.
The distinction is that
a queue's inability to deliver a value
is often not an error,
but simply a normal part of interacting with concurrent objects.
For example, try_pop
can return queue_op_status::empty
,
which clearly does not indicate an error.
The distinction has a design effect when more than one status may be associated with a value. For example, a concurrent queue could provide both a status indicating success with low contention and a status indicating success with high contention. In both cases, the value alone provides less information.
So, we prefer a design in which a status is always provided, but the value is optional. Users of the design will need to define status's have values.
The design is a simpler version of that which appears in N4109 A proposal to add a utility class to represent expected monad - Revision 1.
The working name for the proposed class is status_value
.
template<typename Status, typename Value> class status_value;
Construction of a status_value
can be done with or without a value.
status_value::status_value(Status s); status_value::status_value(Status s, Value&& v); status_value::status_value(Status s, const Value& v);
Construction of status_value
must include a status.
status_value::status_value() = delete;
A status_value
may be moved.
At present, we see no need for copying, but we could be convinced otherwise.
status_value::status_value(status_value&& sv);
They may be queried for status. The design assumes that the status is cheap and copyable, which enables more efficient return-by-value.
Status status_value::status() const;
They may be queried for wither or not they have a value.
bool status_value::has_value() const; status_value::operator bool() const;
They may provide access to their value. If they have no value, an exception of type Status, with the status value passed to the constructor the constructor, is thrown. This design enables moving out of the class.
const Value& status_value::value() const; Value& status_value::value(); const Value& status_value::operator *() const; Value& status_value::operator *();
The outlined solution changes typical code for the proposed concurrent queue from
Value e = q.value_pop();
into
Value e = q.value_pop().value();
and from
Value e; queue_op_status s = q.try_pop(e); if ( s == queue_op_status::success ) do_something_with(e); else do_something_else_with(s);
into
auto sv = q.try_pop(); if ( sv.status() == queue_op_status::success ) do_something_with(sv.value()); else do_something_else_with(sv.status());
or for handling all status's that have values
if ( auto sv = q.try_pop() ) do_something_with(*sv); else do_something_else_with(sv.status());