Add our first async thread sequence

Gave me some ideas about how things should be structured. Apparently
merely using region-data-locked threads doesn't eliminate the need
for synchronization/locking. It just means your synchronization is much
lighter, in the form of localized variables.

It seems we'll need to maintain boolean trackers for certain
operations that shouldn't be performed concomitantly, and deny
the caller access to those operations in order to preserve
data sanity.

I guess we still ended up using locking after all. Tbh, I'm not even
sure this will make things end up being lighter: we may have to bounce
requests off, or perhaps re-enqueue them into the queue?

So maybe instead of bouncing requests off, we could re-add them to the
rear of the queue when they conflict with an ongoing request.
This commit is contained in:
2025-08-29 17:42:13 -04:00
parent bb7be7fb3c
commit d217354689
3 changed files with 121 additions and 0 deletions
@@ -8,6 +8,8 @@
#include <utility>
#include <iostream>
#include <user/deviceAttachmentSpec.h>
#include <deviceManager/device.h>
#include <functional>
namespace smo {
namespace device {
@@ -27,6 +29,11 @@ public:
static const std::string stringifyDeviceSpecs(void);
// New async function for device attachment
void newDeviceAttachmentSpecInd(
std::shared_ptr<DeviceAttachmentSpec> spec,
std::function<void(bool success, std::shared_ptr<Device> device, std::shared_ptr<DeviceAttachmentSpec> deviceSpec)> callback);
private:
DeviceManager() = default;
~DeviceManager() = default;
@@ -41,6 +48,7 @@ public:
extrospectorDeviceSpecs;
static std::vector<std::shared_ptr<DeviceAttachmentSpec>>
deviceAttachmentSpecs;
static std::vector<std::shared_ptr<Device>> devices;
};
} // namespace device