stotko
commented
1 year ago Although queue and stack would also profit from the execution policy support, their primary intention is to serve as special cases for the more general deque and only provide a simplified interface. Extended the support to these containers can be reiterated in the future.
Thus, the task is complete and can be closed.
As the containers should mimic their C++ counterparts as close as possible in terms of functionality, both per-element and iterator-based member functions are considered and provided. While the former allow for easy usage in the native context, that is e.g. in CUDA kernels for the CUDA backend, the latter iterator-based versions can be considered following
algorithmsemantics. However, they lack support forexecution_policys prohibiting greater flexibility such as using asynchronous CUDA streams. The affected functionality is listed below:createDeviceObjectanddestroyDeviceObject~bitset:~set,reset,flip,count,all,any,none~deque:~clear,device_range,valid~memory:~createDeviceArray,destroyDeviceArray, and for symmetry reasons also the respective host versions~mutex:~valid~queue:validstack:validunordered_map,unordered_set:~device_range,insert,erase,clear,valid~vector:~insert,erase,clear,valid~Option 1: Add a respective
execution_policyparameter to all of these functions. This could either followalgorithmand make this the first parameter such that each functions must be duplicated. Alternatively, it could be passed as the last parameter with a default value, at the cost of an inconsistent interface toalgorithm.Option 2: Add a
scoped_execution_policyclass which acts as a customizable default policy for all calls within its scope. While this minimizes the required changes for the containers, proper global management may be hard to implement as the class types of the policies could theoretically be arbitrary.