Lazy sycl::queue creation in oneDPL hetero policies

[SergeyKopienko]

Attention: ABI breaking change.

Yet another approach to lazy sycl::queue creation in oneDPL hetero policies:

• the source issue described at Using oneDPL forces client to always run with "SYCL device" present #1060
• the previous approach has been implemented by @adamfidel in the PR Lazy initialization of queue inside dpcpp_default policy #1154

The main implementation detail is std::once_flag and ::std::call_once usage packed into separate container

template <class TSYCLQueueFactory>
class sycl_queue_container
{
  public:
    template <typename... Args>
    sycl::queue
    get_queue(Args&&... args)
    {
        ::std::call_once(__is_created, [&]() {
            TSYCLQueueFactory factory;
            __queue.emplace(factory(::std::forward<Args>(args)...));
        });

        assert(__queue.has_value());
        return __queue.value();
    }

  private:
    ::std::once_flag __is_created;
    ::std::optional<sycl::queue> __queue;
};

This container shares between hetero policies instances:

template <typename TFactory>
using sycl_queue_container_ptr = ::std::shared_ptr<sycl_queue_container<TFactory>>;


// ...


template <typename KernelName = DefaultKernelName, class TSyclQueueFactory = TDefaultSYCLQueueFactory>
class device_policy
{
  public:
    // ...

  private:
    mutable sycl_queue_container_ptr<TSyclQueueFactory> q_container;       // <<<<<<-- shared sycl::queue container
};

From my point of view this approach is correct because it's simple repeat something like sycl::queue implementation (pimpl-implementation) and we don't introduce any new synchronization errors here.

[kboyarinov]

Do we need this function as part of public API?

[kboyarinov]

Just an idea:
Consider changing sycl_queue_container_ptr::get_queue() to be const and sycl_queue_container_ptr::__queue to be mutable.
For me, it can be unclear why q_container is mutable from the device_policy implementation perspective.

[kboyarinov]

As far as I can see in oneDPL specification - device_policy class is a public API and hence its template parameters are also documented. So do we think that it is necessary to have TSyclQueueFactory template parameter as part of public API?

[SergeyKopienko]

In this valiant - probably yes.

[akukanov]

After merging #1652, this patch is outdated.