Is your feature request related to a problem? Please describe.
The value of static_map::get_size() is only guaranteed to be correct if a user goes through the bulk static_map::insert API. I
If instead a user calls get_device_mutable_view(), then there it is likely that the user inserted keys into the map, but there is no way for us to know how many keys were inserted. Therefore, the value of static_map::get_size() is no longer valid.
Describe the solution you'd like
Invalidate the value of static_map::get_size() whenever a user calls static_map::get_device_mutable_view(). Likewise, provide a static_map::set_size() API for the user to tell us how many keys they inserted (their responsibility to make sure it is accurate).
We can do two things after static_map::get_size() has been invalidated:
- Throw an exception stating that
get_size() cannot be called after get_mutable_device_view() unless set_size() has been called.
- Launch a kernel to recompute the size.
Option 2. would be more convenient, but a potential performance pitfall. Option 1 requires more user effort, but less of a chance of a performance pitfall.
Is your feature request related to a problem? Please describe.
The value of
static_map::get_size()is only guaranteed to be correct if a user goes through the bulkstatic_map::insertAPI. IIf instead a user calls
get_device_mutable_view(), then there it is likely that the user inserted keys into the map, but there is no way for us to know how many keys were inserted. Therefore, the value ofstatic_map::get_size()is no longer valid.Describe the solution you'd like
Invalidate the value of
static_map::get_size()whenever a user callsstatic_map::get_device_mutable_view(). Likewise, provide astatic_map::set_size()API for the user to tell us how many keys they inserted (their responsibility to make sure it is accurate).We can do two things after
static_map::get_size()has been invalidated:get_size()cannot be called afterget_mutable_device_view()unlessset_size()has been called.Option 2. would be more convenient, but a potential performance pitfall. Option 1 requires more user effort, but less of a chance of a performance pitfall.